Re: Detaching from a remote progam: Why does GDB retain breakpoints?

["Anmol P. Paralkar" <b07584@freescale.com>]

On Wed, 8 Oct 2008, Pedro Alves wrote:

> 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
>

Hello Pedro,

  No, the remote program does not have any unremoved breakpoints: GDB properly
  sets and removes them - I see the pre Z's and post z's as and when expected
  in the interaction between GDB and the remote target stub.
  OK, it's just a UI issue then. Thanks.

Best Regards,
Anmol.