[PATCH 2/2] Trace fork series calls using PTRACE_SETOPTIONS on linux

[Wang Chao]

Sent on 2010-9-10 16:31, Roland McGrath wrote:
> Indeed I think it's only some 2.4 kernels that behave in the problematic
> fashion.  But strace has always been compatible with quite old kernels
> before, and we don't want to regress in that compatibility.

> I'm not sure we're understanding each other.  In what I described, there
> would be no lack of the benefits of PTRACE_SETOPTIONS.  In the first call
> to clone/etc, we'd still do the old setbpt work, but also get the new
> ptrace report.  Thereafter, having seen a PTRACE_EVENT_CLONE etc., we would
> never use setbpt again.

Yeah, this method is a good way to keep the compatibility with old kernels
and I'm working on the patch now.

> For the new Linux setbpt code that just changes registers instead of doing
> breakpoints, I think we could make that support proper vfork too.  Right
> now, it turns a vfork syscall into a clone syscall just like a fork syscall.
> We could make that CLONE_PTRACE | CLONE_VFORK | CLONE_VM | SIGCHLD.
> We might have to make sure that more registers get restored to their
> original values, but perhaps that is already done OK.

I doubt it is not that easy. With these flags set, I think strace and the
program it traced won't end up normally since strace will now block the
new child when it returns from fork series calls first until its creater
returns from that syscall. This conflicts with the logic of vfork.

Actually, when new child return from fork series syscall first, strace
can not easily get its parent's pid and determine its parent relationship
and thus can not do the clearbpt work. I guess that's why strace choose
to block new child if it returns first. Maybe /proc/<pid>/stat may help us
to get its parent id, but I'm not sure this method is portable. Moreover,
new child's parent is not always its creater who has done the setbpt work,
for example, clone call with CLONE_PARENT flag.

Do you have any suggestion here? Sorry if I don't understand correctly.

Thanks,
Wang Chao