Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-debug-dev] determining which breakpoint was hit

> 
> >> I will start looking at internals and GDB MI interface to see if I
> can=20
> >> find a temporary solution.
> >
> > The fix is to emulate this by getting all the threads and fire a
> suspend event
> > for all of them.
> 
> The part I'm really looking for is finding which IBreakpoint was hit,
> causing
> the suspend event.
> 
> Looking into it more, I see that CThread's getBreakpoints() just returns
> null,
> so I'm pretty sure the information is just not available publicly in CDT
> 1.2.
> 
> Happily, in the MIBreakpointHitEvent class, the bkptno member is already
> there
> that contains the GDB breakpoint ID. I'm assuming CDT uses these IDs to
> talk
> with GDB, and so there will probably be some way to map that number back
> to
> the corresponding IBreakpoint.
> 
> I'll keep looking at it and hope to provide a patch for a future CDT.
> 

When the SuspendedEvent comes in, the reason will be breakpoint-hit
which indicates the breakpoint.

ICDISuspendedEvent .. {
  getReason();  ---> instanceof ICDIBreakpointHit
}

ICDIBreakpointHit .. {
   getBreakpoint();
}

When a SuspendEvent is trigger there is usually a reason,
- ICDIBreakpointHit
- ICDISignalReceived
- ICDIEndSteppingRange
- ICDIWhatchpointTrigger
- ICDIWhatchpointScope

You can then extract the relevant information; breakpoint, watchpoint, signal etc ..

CDT provides a layer, CDI(Debug API layer) to insulate from
the backend debugger.  You should not have any reason to
poke around the depend layer, which may change from debugger to debugger
and even from different version of MI.


What are you trying to achieve ?




Back to the top