[lkml]   [2011]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v3] Make PTRACE_SEIZE set ptrace options specified in 'data'
    On Saturday 10 September 2011 13:19, Pedro Alves wrote:
    > On Friday 09 September 2011 21:03:10, Denys Vlasenko wrote:
    > > execve is such a rare syscall the one extra stop on it is not
    > > going to be a problem.
    > >
    > > > And about not needing to handle the magic unadorned SIGTRAP.
    > > > The magic unadorned post-exec SIGTRAP does not have `status & 0xff00'
    > > > set, it is not a ptrace event!
    > >
    > > What SIGTRAP? With PTRACE_O_TRACEEXEC, there is no SIGTRAP.
    > But _without_ PTRACE_O_TRACEEXEC there is. You've raised its
    > existence as justification for needing to be able to set
    > options directly on PTRACE_SEIZE.

    It was an example. There may be other options with similar
    problem of "we want to enable new behavior ASAP, without
    waiting fro the first ptrace-stop".

    > Point is, if we don't get rid
    > of the SIGTRAP when PTRACE_O_TRACEEXEC is _not_ in effect, then
    > _everyone_ will always pass PTRACE_O_TRACEEXEC to SEIZE.

    Yes, that's the nature of many options: they are fixing
    ptrace quirks, and therefore newer programs which know about
    these options will _always_ use them. For example, should we
    also unconditionally enable PTRACE_O_TRACESYSGOOD?

    > > > If we don't disable the magic SIGTRAP, there's no way for a
    > > > tracer to do a very non-invasive SEIZE, say, a GDB mode that
    > > > only cares to let the tracer run free to catch SIGSEGVs
    > > > in some child, while later on during the run, the user remembers
    > > > to set a breakpoint. At that point the tracer needs to catch
    > > > exec events, so it'd enable TRACE_O_EVENTEXEC. Getting rid of
    > > > the SIGTRAP gets rid of the spurious stops when TRACE_O_EVENTEXEC
    > > > is not enabled.
    > >
    > > This part I don't understand.
    > Say, you run the whole of gcc's testsuite under gdb, and
    > let it run until one of the children SIGSEGVs. You do "gdb make; run".
    > Currently, all the children stop momentarily for fork/vfork/exec,
    > which slows down the run significantly (there are thousands of
    > forks/execs).

    I doubt about "significantly". fork and exec are heavy syscalls
    (they trash entire L1 data cache on today's CPUs), a ptrace stop
    on top of that is perhaps 10% slowdown _of the syscall_,
    about a few % slowdown overall.

    > We should be able to only SEIZE the shell that runs
    > "make" (gdb runs the child through the shell, like "sh -c make"),
    > and let all its children run free, the least invasive way possible.


    > When a SIGSEGV happens, gdb can sync up about the process that crashed
    > from /proc.

    It doesn't need to do even that - but probably will, gdb code is said
    to be quite complex. I think current code will require auto-attach stops
    in forked children anyway (for parent-child accounting and such),
    and it will require a serious rewrite to get rid of that requirement.


     \ /
      Last update: 2011-09-10 13:43    [W:0.042 / U:21.600 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site