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

Wang Chao wang.chao at cn.fujitsu.com
Fri Sep 3 00:21:42 UTC 2010

于 2010-9-2 9:29, Roland McGrath 写道:
> Unfortunately, it's not quite that easy.  There were some older kernels
> that had PTRACE_SETOPTIONS but did not support PTRACE_O_TRACECLONE et al,
> and also did not check the argument to PTRACE_SETOPTIONS, so they just
> return success without actually enabling the feature you wanted.
> So, when PTRACE_SETOPTIONS succeeds, then you still need to assume that
> PTRACE_O_* is not enabled until you manifestly get a wait result that uses
> PTRACE_EVENT_CLONE et al.  So, the existing code needs to stay as it is for
> at least the first run of a clone*/*fork call.  Then, if the kernel really
> supports the feature, you will get a PTRACE_EVENT_{CLONE,*FORK} stop after
> that syscall-entry stop and before its corresponding syscall-exit stop.
> When that happens, you can record that the kernel really does support the
> feature and then for the next clone*/*fork syscall you won't need to bother
> with the old code (though you still need to finish up in the old fashion at
> that syscall's exit stop).
Got it. I will look deeper into this and try to think out a solution.
> Also note that Andreas had submitted a patch to use PTRACE_SETOPTIONS for
> another purpose (PTRACE_O_TRACEEXEC).  That use also has to cope with the
> kernel support level issue in the same dynamic and resilient fashion.
> These should obviously share some code and play well together.
> Unfortunately, Andreas stopped discussing the issues related to exec
> changes I raised while reviewing that patch, and the change was never
> completed.
OK. I will go to maillist archivers to see what happened.
> Thanks,
> Roland

Wang Chao

More information about the Strace-devel mailing list