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

Oops, this should be the part of the patch that sets the flag:

_at__at_ -873,6 +872,12 _at__at_ 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.
>
>
>