From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25501 invoked by alias); 12 Sep 2009 15:03:23 -0000 Received: (qmail 25249 invoked by uid 22791); 12 Sep 2009 15:03:21 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 12 Sep 2009 15:03:17 +0000 Received: (qmail 22649 invoked from network); 12 Sep 2009 15:03:15 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Sep 2009 15:03:15 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, danny.backx@scarlet.be Subject: Re: Build question Date: Sat, 12 Sep 2009 15:03:00 -0000 User-Agent: KMail/1.9.10 Cc: tromey@redhat.com, Eli Zaretskii References: <1250803105.11282.96.camel@pavilion> <200909111622.34265.pedro@codesourcery.com> <1252766961.8804.38.camel@pavilion> In-Reply-To: <1252766961.8804.38.camel@pavilion> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909121603.15919.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00369.txt.bz2 On Saturday 12 September 2009 15:49:21, Danny Backx wrote: > On Fri, 2009-09-11 at 16:22 +0100, Pedro Alves wrote: > > On Friday 11 September 2009 15:42:53, Danny Backx wrote: > > > Question : it looks like breaking a gdb-gdbserver session always kills > > > the inferior. Or at least it does so on my target. Has this been subject > > > of research yet ? I would expect it to be possible to detach without > > > killing the inferior, much like you can when debugging a linux process > > > from a linux gdb. > > > > What do you mean by breaking, and what do you mean by > > detaching? Please be specific. > > Good question :-) Turns out I had not analysed my question sufficiently > before sending this mail. > > What I was looking for is for gdbserver (and the inferior) to linger > after disconnecting gdb-gdbserver, until I reconnect to it with maybe > another gdb session. > > Maybe my question is a bit too funky. > > > Neither DebugActiveProcessStop nor DebugSetProcessKillOnExit were support > > by Windows CE up until version 5. I see that DebugActiveProcessStop > > was added to CE 6.0: > > > Try checking if DebugActiveProcessStop is non-NULL here on > > your CE >= 6.0 device, and tweak this code to make it possible to detach > > with DebugActiveProcessStop even if we don't support > > DebugSetProcessKillOnExit. > > \network\x86> testapi coredll DebugActiveProcessStop > coredll implements DebugActiveProcessStop (0x4003F4F0) > \network\x86> testapi coredll DebugSetProcessKillOnExit > coredll implements DebugSetProcessKillOnExit (0x4003F510) > \network\x86> So your device supports both DebugActiveProcessStop and DebugSetProcessKillOnExit then. > > (In fact, I don't understand why DebugSetProcessKillOnExit is > > needed here. does Windows really kill a detached inferior when > > gdbserver exits _after_having_detached_from_it_?) > > No, I don't see that. FYI see two examples below, both show both the gdb > and gdbserver session (they're on my screen in two xterms). What I meant by that, was: I was wondering if when you detach with the DebugActiveProcessStop api, while DebugSetProcessKillOnExit is set to true, Windows is dump enough to kill the former inferior when gdbserver exits. If not, then it looks like we don't need that call to DebugSetProcessKillOnExit there, ever. And I wondered about that because the link I showed you referred that support for DebugActiveProcessStop was added to CE 6.0, while DebugSetProcessKillOnExit wasn't. But your test app shows that DebugSetProcessKillOnExit is supported in your device... > > Scenario 1 : detach gdb (from gdbserver) > -> gdbserver appears to detach from inferior > -> gdbserver terminates > -> inferior continues to run > > (gdb) target remote ebox:9999 > Remote debugging using ebox:9999 > (gdb) detach > Ending remote debugging. > (gdb) So, gdbserver's "detach" already works fine as is? > > \network\x86> gdbserver :9999 /network/x86/usedemo.exe > Process /network/x86/usedemo.exe created; pid = 88473610 > Listening on port 9999 > Remote debugging from host 172.17.1.10 > Detaching from process 88473610 > \network\x86> In main > Message from DLL > After DLL call > > Scenario 2 : quit gdb > -> gdb tells gdbserver to terminate inferior > -> gdbserver terminates inferior > -> gdbserver terminates > > (gdb) target remote ebox:9999 > Remote debugging using ebox:9999 > (gdb) q > A debugging session is active. > > Inferior 1 [Remote target] will be killed. > > Quit anyway? (y or n) y > > > \network\x86> gdbserver :9999 /network/x86/usedemo.exe > Process /network/x86/usedemo.exe created; pid = 92536842 > Listening on port 9999 > Remote debugging from host 172.17.1.10 > Killing all inferiors > \network\x86> And this is also working as expected? What's the problem then? -- Pedro Alves