Re: [ptrace] please review follow fork/exec changes

> 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.