> I'm not sure what Andreas's PTRACE_SETOPTIONS patches are, as I've
> just joined the list.
It uses PTRACE_O_TRACESYSGOOD and PTRACE_O_TRACEEXEC to avoid both being
confused by, and interfering with, normal SIGTRAP signals used by the
program.
> But I have just written a different PTRACE_SETOPTIONS patch to use
> PTRACE_O_TRACE{FORK,VFORK,CLONE}, so that it's possible to trace vfork
> without converting it to fork. That is essential on uClinux where
> fork isn't an option, and tracing vfork just freezes with the current
> strace. But it's also a cute improvement for regular Linux.
That is also worthwhile, though substantially more hairy to do perfectly.
This fits in with Andreas's changes and should happen after they are
finalized.
> It works well and I've tried to keep it as tidy as one can given the
> messy strace starting point, but I'm sure that it needs a round of
> review before it is committed, if it ever is.
>
> What's the interested level in that kind of patch?
It's a fine thing to do. As with the simpler patch, the hairiest part of
the problem is robustly handling varying levels of support in different
kernels without assuming you know what works until you've seen it work.
That is quite a lot more complex in the fork/clone case in ways we can get
into in the review. I suspect those changes will be more than hairy enough
that we'd put them off past 4.5.21 even, assuming Andreas's simpler changes
go into 4.5.21.
Thanks,
Roland
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
