From: Pedro Alves <pedro@codesourcery.com>
To: gdb@sourceware.org
Cc: "Anmol P. Paralkar" <b07584@freescale.com>
Subject: Re: Detaching from a remote progam: Why does GDB retain breakpoints?
Date: Wed, 08 Oct 2008 22:24:00 -0000 [thread overview]
Message-ID: <200810082324.17293.pedro@codesourcery.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0810081207460.8437@ld0159-tx32>
On Wednesday 08 October 2008 23:01:57, Anmol P. Paralkar wrote:
> I am trying to understand the 'detach' command and need your help.
>
> The documentation says:
>
> "After the detach command, gdb is free to connect to another target."
>
> So, why does GDB retain breakpoints after detaching from the remote target?
GDB shouldn't be leaving breakpoints installed in the target on a detach. If it
is, it is a bug.
If you refering to breakpoints as what is listed by "info breakpoints", we just
keep them, well, that's a user interface issue. We leave them because we can, it
can be useful. Just like we keep breakpoint if the program just exits normally
after a "run".
> The documentation for 'disconnect' indicates that GDB could possibly re-connect
> to the same remote target so I can see why it makes sense to retain breakpoints
> on a 'disconnect'. But, with a 'detach', a D-packet is sent and I suppose stubs
> will then typically relinquish control and have the target proper take over.
>
> Should'nt GDB clear out all its target related debug-state on a 'detach'?
>
You should be seeing GDB removing the breakpoints from the target before
you see the 'D' packet: either with `z' packets if the stub supports them,
or memory writes otherwise. Is this what you meant?
--
Pedro Alves
next prev parent reply other threads:[~2008-10-08 22:24 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-08 22:02 Anmol P. Paralkar
2008-10-08 22:24 ` Pedro Alves [this message]
2008-10-08 22:47 ` Anmol P. Paralkar
2008-10-08 22:56 ` Michael Snyder
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=200810082324.17293.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=b07584@freescale.com \
--cc=gdb@sourceware.org \
/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