This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Detaching from a remote progam: Why does GDB retain breakpoints?
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb at sourceware dot org
- Cc: "Anmol P. Paralkar" <b07584 at freescale dot com>
- Date: Wed, 8 Oct 2008 23:24:16 +0100
- Subject: Re: Detaching from a remote progam: Why does GDB retain breakpoints?
- References: <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