This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Disabling breakpoints does not work if rejected from remotestub
- From: Michael Snyder <Michael dot Snyder at palmsource dot com>
- To: Sascha <sascha at pasalacqua dot de>
- Cc: 'Daniel Jacobowitz' <drow at false dot org>, gdb at sourceware dot org
- Date: Tue, 06 Mar 2007 11:44:33 -0800
- Subject: Re: Disabling breakpoints does not work if rejected from remotestub
- References: <000001c75a51$cc99f0c0$02b2a8c0@insanenotebook> <20070227115524.GA5164@caradoc.them.org> <001501c75a91$8843c910$02b2a8c0@insanenotebook> <1173125452.29183.17.camel@localhost.localdomain> <004401c75fc2$698386b0$02b2a8c0@insanenotebook>
On Tue, 2007-03-06 at 08:38 +0100, Sascha wrote:
> Hi
>
> >>However, the more serious error is that at this point, the
> "run" (or "step") command is aborted, returning to the gdb
> prompt, but without removing the breakpoints. The error handling
> code at this point ought to remove all of the breakpoints that
> have been inserted.
>
> I guess GDB does not have to remove the breakpoints at that point - as long
> as it will remember them later on.
No, that's not how gdb works (unles there's a change that I
don't know about). We don't leave 'em in, we always remove 'em.
> You simply have to compare the "DELETE
> BP1/BP2" section and the "DISABLE BP1/BP2" section in the log.
>
> _Deleting_ the breakpoints causes GDB to send the required "z0" (bp remove)
> packets for those breakpoints which have been inserted already.
>
> _Disabling_ the breakpoints does nothing. No "z0" packets were send to the
> stub.
That's odd. Doesn't sound right.
>
> So I guess the fix is to make GDB send the required z0 packets for disabled
> breakpoints - just like it does for deleted breakpoints.
Could be.