Skip to main content

[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: March-16-10 7:24 AM
> To: CDT General developers list.; 'CDT General developers list.'
> Subject: 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.

Ok with me.

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

If you look at GDBBreakpoints_7_0, it recently started being used.
But now that we talk about it, I wonder if it ever actually gets
triggered since it is MIBreakpointsManager which prevents
setting bps that are disabled...

BTW, this is an example of stuff the MIBreakpointsManager does
that we have to be careful not to loose if we migrate to 
the BreakpoinMediator (bug 219604).



Back to the top