From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org, danny.backx@scarlet.be
Cc: tromey@redhat.com, Eli Zaretskii <eliz@gnu.org>
Subject: Re: Build question
Date: Sat, 12 Sep 2009 15:03:00 -0000 [thread overview]
Message-ID: <200909121603.15919.pedro@codesourcery.com> (raw)
In-Reply-To: <1252766961.8804.38.camel@pavilion>
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
next prev parent reply other threads:[~2009-09-12 15:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1250803105.11282.96.camel@pavilion>
[not found] ` <m3fxbl2jib.fsf@fleche.redhat.com>
[not found] ` <83d46pgjkq.fsf@gnu.org>
[not found] ` <1250877901.11282.116.camel@pavilion>
[not found] ` <83ab1tgh9h.fsf@gnu.org>
[not found] ` <1250880746.11282.128.camel@pavilion>
[not found] ` <m3r5v425lu.fsf@fleche.redhat.com>
[not found] ` <1250931899.11282.142.camel@pavilion>
[not found] ` <83skfkfa4n.fsf@gnu.org>
[not found] ` <1251095160.16357.352.camel@pavilion>
[not found] ` <1251828295.6106.119.camel@pavilion>
[not found] ` <83zl9e8nro.fsf@gnu.org>
[not found] ` <1251835928.6106.124.camel@pavilion>
[not found] ` <83vdk281xb.fsf@gnu.org>
[not found] ` <1252143311.6106.252.camel@pavilion>
2009-09-05 16:12 ` Eli Zaretskii
2009-09-07 22:12 ` Joel Brobecker
2009-09-08 15:53 ` Danny Backx
2009-09-08 20:13 ` Danny Backx
2009-09-09 19:57 ` Tom Tromey
2009-09-11 14:41 ` Danny Backx
2009-09-11 15:22 ` Pedro Alves
2009-09-11 15:28 ` Pedro Alves
2009-09-12 14:48 ` Danny Backx
2009-09-12 15:03 ` Pedro Alves [this message]
2009-09-12 16:58 ` Danny Backx
2009-09-13 16:10 ` Pedro Alves
2009-09-13 18:07 ` Danny Backx
2009-09-12 14:53 ` Danny Backx
2009-09-13 9:30 ` Danny Backx
2009-09-13 16:04 ` Joel Brobecker
2009-09-14 18:03 ` Tom Tromey
2009-09-14 18:25 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200909121603.15919.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=danny.backx@scarlet.be \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox