[lldb-dev] Pending breakpoints strategy?

[jingham at apple.com]

The easiest way is to add these events to whatever SBListener you are using to wait on process events.  You add events to a Listener using the SBListener::StartListeningForEvents API.  You can either listen for some event types on a particular broadcaster (some one target) but it is probably easier to listen to those event types for a class of broadcasters (all targets.)  So for instance, if "my_debugger" is your debugger, and "my_listener" is the listener you are using for all other debugger events, do something like:

my_listener.StartListeningForEventClass(my_debugger, SBTarget::GetBroadcasterClass(), SBTarget::eBroadcastBitBreakpointChanged);

Then in your event handling loop, check if the event's class is SBTarget, and then use the static functions in the SBBreakpoint class to unpack the event.

Jim


On Apr 22, 2014, at 11:06 AM, Eran Ifrah <eran.ifrah at gmail.com> wrote:

> 
> 
> 
> On Tue, Apr 22, 2014 at 9:02 PM,  <jingham at apple.com> wrote:
> lldb will take care of this for you.  When the dylib that contains the file & line or name you specified gets loaded, the dynamic loader plugin notifies the breakpoints that some modules have been added and those modules will be searched for new breakpoint matches.
> 
> ​I figured that this is done automatically, this is why I decided to ask before re-inventing the wheel...
> ​
> Note that this means that if you did a breakpoint by name, it could start out with some number of "breakpoint locations" but that number can grow or shrink over time as libraries get loaded or unloaded.
> 
> If you listen to the eBroadcastBitBreakpointChanged bit on the SBTarget, you will get notified when this happens and can update your UI accordingly.
> Is there an example of how to do this? (pseudo code, python, c++ anything ;)
> ​
> 
> Jim
> 
> On Apr 22, 2014, at 10:54 AM, Eran Ifrah <eran.ifrah at gmail.com> wrote:
> 
> > Hi,
> >
> > While experimenting with my new lldb plugin, I placed a breakpoint inside a shared object (using file:line / name ) which is loaded via 'dlopen'
> >
> > My stratey so far for breakpoints was:
> >
> > - Create debugger
> > - Create the target
> > - Launch target with the flag 'lldb::eLaunchFlagStopAtEntry'
> > - When stopped on first entry, all breakpoints are being applied using m_target.BreakpointCreateByName / BreakpointCreateByLocation
> > - The plugin then queries lldb to get a complete list of breakpoints andupdate the UI (some breakpoint are resolved to multiple locations, moved if they were placed on a comment etc) like this:
> >
> > int num = m_target.GetNumBreakpoints();
> > for(int i=0; i<num; ++i) {
> >         lldb::SBBreakpoint bp = m_target.GetBreakpointAtIndex(i);
> > ...
> > }
> >
> > At this point, I can see that the breakpoints I have applied in the shared libraries were not applied. So my question is:
> > Who should be responsible for the "pending" breakpoints? Is it done automatically by lldb? or should I keep a list of un-applied breakpoints and try to re-apply them later on?
> >
> > If the later is the case, can the plugin be notified when a shared library is loaded? (this seems like a good candidate for trying to re-apply pending breakpoints)
> >
> > Thanks,
> >
> > --
> > Eran Ifrah
> > Author of codelite, a cross platform open source C/C++ IDE: http://www.codelite.org
> > wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> 
> 
> 
> -- 
> Eran Ifrah
> Author of codelite, a cross platform open source C/C++ IDE: http://www.codelite.org
> wxCrafter, a wxWidgets RAD: http://wxcrafter.codelite.org