[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] disabled breakpoints
|
At 09:14 PM 3/15/2010, Marc Khouzam wrote:
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
> Sent: Monday, March 15, 2010 7:08 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] disabled breakpoints
>
> Just saw something interesting in MIBreakpoints.addBreakpoint() that
> makes me wonder whether there's a use case that's broken. For a
> disabled breakpoint, DSF-GDB tells gdb to set the breakpoint then
> makes a subsequent request to disable it.
We used to do it like that, which is why the code in MIBreakpoints
still looks the way it does. However, we ran into a Non-Stop problem
where we could create a breakpoint and before we had time to disable it,
it would hit. To fix this (bug 261082), we no longer set a breakpoint
if it starts off in the disabled state. This is done in
MIBreakpointsManager.installInitialBreakpoints().
I think we should remove the "dead" code, then. Stuff like that can
only mislead developers trying to read and understand the code. We
should replace it with an assert that verifies that code isn't deal
with a disabled breakpoint. I'll take care of that unless you object.
> Consider a target with support for one hardware breakpoint. The user
> has two hardware breakpoints defined before he launches a debug
> session; one is disabled. He launches the debug session. Unless I'm
> misinterpreting things, what's going to happen is we're going to
> attempt to set that second breakpoint and that's going to fail, no?
> Seems to me should be creating the breakpoint in the disabled state
> (MI supports this: -break-insert -d).
That is a new option with GDB 7.0 that we requested for CDT :-)
But it is not available before GDB 7.0 :-(
Nice. I guess we'll use it down the road.
