From owner-freebsd-current@FreeBSD.ORG Mon Jan 30 21:05:58 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 C3F581065673 for ; Mon, 30 Jan 2012 21:05:58 +0000 (UTC) (envelope-from dmitrym@juniper.net) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by mx1.freebsd.org (Postfix) with ESMTP id 58EE58FC15 for ; Mon, 30 Jan 2012 21:05:58 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTycGNDMoJTyJaESBGK5Yeu+lrfE9TLuK@postini.com; Mon, 30 Jan 2012 13:05:58 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 13:05:22 -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 q0UL5M147809; Mon, 30 Jan 2012 13:05:22 -0800 (PST) (envelope-from dmitrym@juniper.net) Message-ID: <4F270610.80505@juniper.net> Date: Mon, 30 Jan 2012 13:05:20 -0800 From: Dmitry Mikulin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Kostik Belousov 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> In-Reply-To: <20120130192727.GZ2726@deviant.kiev.zoral.com.ua> 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: Mon, 30 Jan 2012 21:06:43 +0000 Cc: 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: Mon, 30 Jan 2012 21:05:58 -0000 >> Gdb needs to be able to read/write process memory between the time the >> child is forked and exec is called (in the vfork case). Without the change >> it causes a kernel panic when gdb tries to read/write process memory. Since >> my understanding of the kernel is a bit limited, it was the best I could do >> at the time. I will send more details about the panic once I get a working >> fbsd system again. Maybe there's a better way to deal with the panic. > Please provide more details, I am looking forward for the panic > message and backtrace. As soon as I get my FreeBSD box fixed, hopefully tomorrow. > >>> Lets postpone discussion of the orphan.patch for later. >> OK. >> >>> The follow-fork.patch and follow-exec.patch make me wonder, and I >>> already expressed my doubts. IMO, all features, except one bug, are >>> already presented in the stock src. >>> >>> More, suggested follow-{fork,exec} patches break the SCE/SCX tracers >>> notification of fork and exec events, since TDB_FORK and TBD_EXEC flags >>> are consumed before syscall returns (I also said this previously). >> >> >> >>> Namely, if the process is being debugged, the successfull [f]execve() >>> causes unconditional stop even. This makes PT_FOLLOW_EXEC unneccessary. >>> >>> Existing PT_FOLLOW_FORK implementation indeed has a bug, which was not >>> revealed by my testing during the development, because I only tested >>> SCE/SCX scenario. Namely, if PT_FOLLOW_FORK is requested, but the next >>> stop is not SCX, then follow-fork notification is not sent. After this >>> nit is fixed, PT_FOLLOW_FORK caller gets stops for the child creation. >>> Child is put into stop state as needed to not loose it. >> I think this will fix only a part of the problem, the one that relates to >> PT_CONTINUE. >> >> I still need the change that forces a stop in both child and parent on >> fork(). Without my changes the notification is generated in the child but >> not in the parent. I need to be able to have both processes stopped in gdb >> in order to clean up and detach from the parent, and initialize and attach >> to the child. The main reason I need both processes stopped is that gdb has >> to be able to read/write into both processes address space and registers. >> Ideally I would like to have a single event generated for fork() at a point >> where both child and parent are stopped and available for ptrace read/write >> requests. Do you think it's possible? > The lack of the notification for parent is exactly what the patch I > posted fixes. More exactly, it is the lack of notification for parent > with PT_CONTINUE loop. I will commit this today. > > Regarding a single notification. Currently, parent arrives at the > syscall return code only after the child is attached to the debugger. > See the cv_wait() in kern_fork.c:739. In other words, if you get the > PL_FLAG_FORK, the child is already attached (at last it shall be). My > scescx.c code illustrates this well, IMO. OK, I see. I need to verify that it works with gdb and possibly tweak it to match the kernel. > > You still get a separate stop from the child, but I do not see how is it > harmful. It's not harmful as long as gdb can tell that those stops are generated by the fork().