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 <[email protected]> wrote: > > > > On Tue, Apr 22, 2014 at 9:02 PM, <[email protected]> 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 <[email protected]> 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 > > [email protected] > > 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 _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
