Oops, this should be the part of the patch that sets the flag:
@@ -873,6 +872,12 @@ kern_ptrace(struct thread *td, int req, pid_t pid,
else
p->p_flag &= ~P_FOLLOWFORK;
break;
+ case PT_FOLLOW_EXEC:
+ if (data)
+ p->p_flag |= P_FOLLOWEXEC;
+ else
+ p->p_flag &= ~P_FOLLOWEXEC;
+ break;
The SIGHUP I mentioned is due to the fact that the parent exits immediately. I
guess that's not a particularly well written program.
On 02/06/2012 01:19 PM, Dmitry Mikulin wrote:
I see what is going on. The wait loop for P_PPWAIT in do_fork() simply
do not allow the ptracestop() in the syscall return path to be reached.
There seems to be more problems. In particular, I do not see anything
which would prevent the child from being reapped while the loop is
executing (assume that the parent is multithreaded and other thread
processed SIGCHLD and called wait).
Lets deal with these bugs after your proposal for interface changes is
dealt with.
OK.
Yes, I agree with the proposal to add flag to the child lwp info.
I think it will be easier if the flag is different from PL_FLAG_FORKED.
I named it PL_FLAG_CHILD.
PT_FOLLOW_EXEC is easy to implement, but my question is, how can debugger
operate (correctly) if it ignores exec events ? After exec, the whole
cached state of the debuggee must be invalidated, and since debugger
ignores the notification when the invalidation shall be done, it probably
gets very confused.
You're right, the debugger needs to handle exec() events implicitly when it
starts up executables. The problem is that there is OS-independent machinery in
gdb which handles statup fork-exec sequence differently from when the debuggee
itself does an exec(). Basically in the event handling code I need to be able
to distinguish app startup by gdb from an exec done by the app. Other OS-es
have flags like PL_FLAG_EXEC set on demand: they have an equivalent of
PT_FOLLOW_EXEC. I attached a modified patch that solves the problem. It tries
to separate the always-on TDB_EXEC from the on-demand TDB_FOLLOWEXEC without
changing existing functionality. Let me know if it's acceptable.
Another issue I'm investigating is that after the switch-over to the child gdb
gets a SIGHUP when it continues the child. I think it has to do with the
re-parenting/orphan business. I'll let you know what I find, but if you have an
idea what might be causing it, please let me know.
Thanks.
Dmitry.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
