Re: PATCH: ptrace support for fork/vfork/clone events [1/3]

[Daniel Jacobowitz <dan@debian.org>]

On Sun, Oct 27, 2002 at 01:53:17PM -0500, Alan Cox wrote:
> > I've submitted this a couple of times and gotten no feedback, but I'm a
> > sucker for pain, so here it is again - I'd really like to see this patch in
> > 2.6.
> 
> I've been ignoring this because it doesn't appear to agree with what other
> people tell me. For example why can't you do the fork trace by building
> a trampoline ?

This is what strace used to do.  You'll notice that Red Hat's doesn't
any more - not sure if that's in a release yet, Roland was working on
it.  I'm not sure exactly how it works now, but the gist of the problem
was that it's unreliable.  I believe the exact problem he was addressing
was that while strace held the process stopped and figured out the
child's PID, the child got a signal.  It leaves the trampoline and goes
off to handle the signal; strace loses track of it, and it either exits
(confusing the tracer) or longjmps (completely escaping the tracer).

The trampolines are platform-specific, too, which is a real nuisance. 
Some of them are still wrong in the strace source.

Another advantage of ptrace reporting this is that we can stop on these
events without having to manage breakpoints on the syscall points in
libc, which is good when people inline-asm a clone() for some reason;
which does still happen.  GDB can't use PTRACE_SYSCALL to find forks,
it's a substantial slowdown for minimal benefit.

I can probably come up with some more reasons if you want :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer