From owner-freebsd-current@FreeBSD.ORG Tue Feb 7 00:47:30 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C60F1065670 for ; Tue, 7 Feb 2012 00:47:30 +0000 (UTC) (envelope-from dmitrym@juniper.net) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by mx1.freebsd.org (Postfix) with ESMTP id 0B52E8FC16 for ; Tue, 7 Feb 2012 00:47:29 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTzB0oHZ8k5kVFar+kWBmdvEc2g6ujp4+@postini.com; Mon, 06 Feb 2012 16:47:30 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 6 Feb 2012 16:46:12 -0800 Received: from [172.24.26.191] (dmitrym-lnx.jnpr.net [172.24.26.191]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q170kA116867; Mon, 6 Feb 2012 16:46:10 -0800 (PST) (envelope-from dmitrym@juniper.net) Message-ID: <4F307452.6030805@juniper.net> Date: Mon, 6 Feb 2012 16:46:10 -0800 From: Dmitry Mikulin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Dmitry Mikulin 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> In-Reply-To: <4F3043E2.6090607@juniper.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 X-Mailman-Approved-At: Tue, 07 Feb 2012 02:11:28 +0000 Cc: Konstantin Belousov , freebsd-current Current , Marcel Moolenaar Subject: Re: [ptrace] please review follow fork/exec changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 00:47:30 -0000 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. > > >