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

[Denys Vlasenko]

On Friday 09 September 2011 19:09, Pedro Alves wrote:
> > This would be a _very_ minor improvement, so tiny it's not worth
> > bothering with. Let me show you the real-world code (part of strace
> > source) which skips over unneeded PTRACE_EVENT_EXEC:
> > 
> >                 if ((status >> 16) != 0)
> >                         /* Ptrace event (we ignore all of them for now) */
> >                         goto restart_tracee_with_sig_0;
> > 
> > Yes. That is all.
> > It probably compiles into just two assembly instructions.
> 
> WTH?  I'm talking about _not forcing the tracee to stop_.  Let
> me repeat.  NOT FORCING THE TRACEE TO STOP.

No need to shout.

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.

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

(btw, PTRACE_O_TRACEEXEC, not TRACE_O_EVENTEXEC).

-- 
vda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/