[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] disabled breakpoints
|
> -----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().
> 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 :-(
