Messages in this thread | | | Date | Tue, 24 May 2011 16:02:15 +0200 | From | Tejun Heo <> | Subject | Re: [PATCH 03/10] ptrace: implement PTRACE_SEIZE |
| |
Hello,
On Tue, May 24, 2011 at 01:36:03PM +0100, Pedro Alves wrote: > 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.
Now that thinking more about it, TRAP_STOP (INTERRUPT trap) would probably be better. I'll think more about it. For fork, it doesn't really matter but deliverying SIGSTOP on CLONE isn't too good. From user's POV, TRAP_STOP should work too, right?
> > 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.
Yes, it would require some sort of synchronization. I was thinking more along the line of ptracer modifying tracee so that it exits pause(2) loop after ptracer issues PTRACE_CONT, but I agree using pipes would be more straight-forward.
Thank you.
-- tejun
| |