[ptrace] please review follow fork/exec changes
kostikbel at gmail.com
Wed Jan 25 07:48:32 UTC 2012
On Tue, Jan 24, 2012 at 01:36:55PM -0800, Marcel Moolenaar wrote:
> Please review the attached changes (done by Dmitry -- CC'd) to add support for
> PT_FOLLOW_EXEC and cleanup PT_FOLLOW_FORK.
> I'll commit this when there are no comments/objections.
I would certainly appreciate some more words describing the changes.
What is the goal of introducing the PT_FOLLOW_EXEC ? To not force
the debugger to filter all syscall exits to see exec events ?
Why did you moved the stopevent/ptracestop for exec events from
syscallret() to kern_execve() ? If moving, why the handling of TDB_EXEC
is not removed from syscallret() ? I do not think that TDB_EXEC can be
seen there after the patch. The same question about TDB_FORK.
If possible, I would greatly prefer to have fork changes separated.
I doubt that disallowing RFMEM while tracing is the right change. It may
be to fix some (undescribed) bug, but RFMEM is documented behaviour used
not only for vfork(2), and the change just breaks rfork(2) for debugged
Even vfork() should not be broken, since I believe there are programs
that rely on the vfork() model, in particular, C shell. It will be
broken if vfork() is substituted by fork(). The fact that it breaks only
under debugger will make it esp. confusing.
Why do we need to have TDB_FORK set for td2 ?
Does the orphan list change intended to not lost the child after fork ?
But the child shall be traced, so debugger would get the SIGTRAP on
the attach on fork returning to usermode. I remember that I explicitely
tested this when adding followfork changes.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20120125/6df321be/attachment.pgp
More information about the freebsd-current