Date: Mon, 6 Feb 2012 16:46:10 -0800 From: Dmitry Mikulin <dmitrym@juniper.net> To: Dmitry Mikulin <dmitrym@juniper.net> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-current Current <freebsd-current@freebsd.org>, Marcel Moolenaar <marcelm@juniper.net> Subject: Re: [ptrace] please review follow fork/exec changes Message-ID: <4F307452.6030805@juniper.net> In-Reply-To: <4F3043E2.6090607@juniper.net> References: <749E238A-A85F-4264-9DEB-BCE1BBD21C9D@juniper.net> <20120125074824.GD2726@deviant.kiev.zoral.com.ua> <4F2094B4.70707@juniper.net> <20120126122326.GT2726@deviant.kiev.zoral.com.ua> <4F22E8FD.6010201@juniper.net> <20120129074843.GL2726@deviant.kiev.zoral.com.ua> <4F26E0D1.8040100@juniper.net> <20120130192727.GZ2726@deviant.kiev.zoral.com.ua> <4F2C756A.80900@juniper.net> <20120204204218.GC3283@deviant.kiev.zoral.com.ua> <4F3043E2.6090607@juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F307452.6030805>