From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6745 invoked by alias); 6 Aug 2013 12:52:25 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 6731 invoked by uid 89); 6 Aug 2013 12:52:25 -0000 X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE autolearn=no version=3.3.1 Received: from Unknown (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 06 Aug 2013 12:52:24 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1V6gkK-00011e-PF from Luis_Gustavo@mentor.com ; Tue, 06 Aug 2013 05:52:16 -0700 Received: from NA1-MAIL.mgc.mentorg.com ([147.34.98.181]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Aug 2013 05:52:17 -0700 Received: from [172.30.2.121] ([172.30.2.121]) by NA1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Aug 2013 05:52:15 -0700 Message-ID: <5200F17D.7040201@codesourcery.com> Date: Tue, 06 Aug 2013 12:52:00 -0000 From: Luis Machado Reply-To: lgustavo@codesourcery.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Pedro Alves CC: "gdb@sourceware.org" Subject: Re: Feature Parity: Remote fork following References: <51E451D7.9020504@codesourcery.com> <51EFF691.1000606@redhat.com> <51FFF307.4070207@codesourcery.com> <5200BD6A.2070404@redhat.com> In-Reply-To: <5200BD6A.2070404@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00009.txt.bz2 On 08/06/2013 06:10 AM, Pedro Alves wrote: > On 08/05/2013 07:46 PM, Luis Machado wrote: > >> Risking creating more work, how does it sound to require even the >> single-process (target remote) mode to use PID's for context, just like >> the extended-remote mode does? I wonder how hard that is and how much >> work is involved there. Implementing single-process mode on top of >> multi-process... similar to all-stop on top of non-stop. > > I'm confused. Is that any different from: > > On 07/24/2013 12:45 PM, Pedro Alves wrote: >>> Originally, the multi-process extensions were always off if you connected >>> with "target remote"; they'd only be available to extended-remote. But >>> nowadays that's no longer true -- multi-process is always available even >>> in "target remote", if the target supports them. The push in that direction >>> had follow-fork in mind. So, if multi-process extensions make this easier, >>> we can just require them. > >> >> A big problem is backwards compatibility in this case. There are a bunch >> of gdbserver/gdb versions out there that would try to speak to each >> other without mentioning PID's no matter what. > > Support for the multi-process extensions is broadcast in qSupported > ("multiprocess+"). This works presently. Try connecting to gdbserver > with plain "target remote", and you'll see PIDs. But if the target > doesn't support the extension, then GDB will still cope. It just wont > support certain things. Fork would just be another of those things. > > Ah, that's what i was talking about. Somehow i had in mind the old "remote" target would deal with thing with no PID's whatsoever. >>> GDB needs to undo things from the child before detaching it >>> (gdb-side breakpoints, displaced stepping, etc.). Only if it's really >>> sure nothing will need to be removed, could pushing follow-fork-mode/detach-on-fork >>> to the remote side be useful. I do believe such an optimization (where >>> the target handles fork following) might be useful for plain "continue until >>> SEGV in some child" scenario, but otherwise, I believe it to be better to start >>> with the basics first. Make catch fork/vfork/exec work, and build up from >>> that. Proper vfork handling, where you have shared memory region between parent/child >>> until TARGET_WAITKIND_VFORK_DONE (which needs RSP modelling as well) also needs to >>> be factored in. >> >> Handling these events inside gdbserver seems to be more straightforward >> than doing back-and-forth to inform GDB of things that are happening. >> >> The problem i see is the lack of displaced stepping support in >> gdbserver. Everything is controlled by GDB in this case. In the future, >> i imagine displaced stepping will just disappear and the debugger will >> just ask for "stepi/step" and things will happen. > > Sure, that's certainly possible, but I'm also certain that there'll always > be corner cases of run control where GDB will need to be informed of the fork > events, even if most handling can be done 99% of the time of the program > run in the server. "catch fork" is the most obvious example. New > fork events are a necessary condition to support these catchpoints, and > everything else can be built on top, while anything beyond the > catchpoints can be seen as optimization work, IMO. Even then, you're > _requiring_ always implementing breakpoints on the server-side that > way -- that complicates the server-side work to support forks on > software single-step targets (ARM, etc.), by a whole lot. Seems desirable > to support those too, without too many requirements. Yeah. server-side for this starts to sound like a potentially broken path for now.