Messages in this thread | | | From | Pedro Alves <> | Subject | Re: [PATCH 03/10] ptrace: implement PTRACE_SEIZE | Date | Tue, 24 May 2011 13:36:03 +0100 |
| |
On Tuesday 24 May 2011 13:00:13, Tejun Heo wrote: > Hello, > > On Tue, May 24, 2011 at 10:49:58AM +0100, Pedro Alves wrote: > > A couple interface questions that just crossed my mind: > > > > - on a fork/vfork/clone, if PTRACE_EVENT_FORK|VFORK|CLONE have been > > enabled, will the tracer still see the new child stop with a > > SIGSTOP, or will it see a PTRACE_EVENT_INTERRUPT? > > This won't change, so SIGSTOP although we probably want to improve it > such that this can be distinguished from SIGTRAP from userland.
(I assume you meant SIGSTOP from userland.) So that if a SIGSTOPs from userland is sent before the tracer waits for the child, the tracer sees a siginfo corresponding to the userland SIGSTOP? Sounds like it might work.
> > - is PTRACE_INTERRUPT on PTRACE_TRACEME-traced-child planed to > > be allowed (for convenience)? > > A PTRACE_O_TRACEINTERRUPT, or some such PTRACE_SETOPTIONS > > option might be necessary to get PTRACE_EVENT_INTERRUPT instead > > of SIGSTOP in the point above. > > I'm currently leaning toward deprecating PTRACE_TRACEME. If a task > can PTRACE_TRACEME, it may as well just do pause(2) and let the parent > SEIZE it.
Debuggers will want to nurse the child through a couple of execs (shell, then real debuggee), so that scheme requires a bit more synchronization, because SEIZE hides the magic exec SIGTRAP, and so the tracer needs to set the O_TRACEXEC option before the first exec, and make sure external signals don't break the synchronization. Reading/writing to/from blocking pipes for that initial synchronization is what GDB uses instead for e.g., hpux/ttrace support, which looks similar to using PTRACE_SEIZE for PTRACE_TRACEME. A bit more cumbersome, though doable, I suppose.
Thanks.
-- Pedro Alves
| |