Hi.
I've done a bit of hacking on strace lately, and I think I can address
these. (The official maintainer is Wichert Akkerman,
<wakkerma@debian.org>.)
The man page is inaccurate with respect to the fork tracing mechanism.
What happens is that strace uses ptrace(PTRACE_POKETEXT...) to insert an
infinite loop following the trap instruction (so it becomes `int $0x80;
jmp .'). So no matter when the child is spawned, it will get stuck in
this loop. When the fork syscall returns in the parents, strace
inspects the return value to find the PID of the child. It then
attaches to this process, patches the original code back in, and sends
it merrily on its way. (It also patches the original code back in to
the parent.) So fork tracing should work regardless of the number of
processors.
For vfork this won't work, as the parent won't return until the child
has done something (exec or exit), and the child is looping. As a hack
to work around this, when strace intercepts a vfork, it uses the
ptrace(PTRACE_POKEUSR, ORIG_EAX...) mechanism [*] to change the system
call back into a plain old fork. I wrote that hack, and decided that it
was reasonable on the grounds that vfork used to just call fork at the
libc level, and anyone who depended on getting special vfork semantics
was asking for trouble anyway.
In short, fork tracing works, and vfork tracing works with a new kernel
or a patch.
There may be better ways to accomplish this; I shall investigate the
methods discussed in this thread. Suggestions are also welcome.
[*] This is the "functionality not yet in the standard kernel", as that
mechanism was disallowed until recent 2.3.x, and required a patch to
enable. I will update the man page to reflect this and to fix the
`fork' error.
Hope this helps.
--Nate Eldredge neldredge@hmc.edu
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/