Re: [PATCH v3] Make PTRACE_SEIZE set ptrace options specified in 'data'

[Denys Vlasenko <vda.linux@googlemail.com>]

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.

True.

> 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.

-- 
vda