Hi Jim, Thanks for the insight into what's going on. I figured I might be misusing the listener stuff. It would be great if there were a way to register for these kinds of events from the python interface.
For now, the stop-hook will suffice. The only issue that I have is with that is registering the stop hook only works when there is a target loaded: (lldb) target stop-hook add -o 'voltron update' error: invalid target (lldb) file ~/Projects/voltron/test_x64 Current executable set to '~/Projects/voltron/test_x64' (x86_64). (lldb) target stop-hook add -o 'voltron update' Stop hook #1 added. Loukas On 10/10/2013, at 3:58 AM, [email protected] wrote: > Right now, having multiple listeners getting process events doesn't really > work. So if you have both the driver listening to process events, and you > try to peek at them from your code as well, that very likely will cause > problems. > > It wouldn't be impossible to make this work. There is some asymmetry in > process events, since some work goes on when the event is first fetched off > the public queue (breakpoint commands get run, etc.) So you'd have to be > careful to make sure that work doesn't get re-done. But it still could be > made to work if needed. It is on our queue of things to clean up, but not > high on the list... > > Jim > > On Oct 9, 2013, at 9:45 AM, [email protected] wrote: > >> Hi Yin, >> >> Voltron is not so much built "on top" of LLDB as it is "glued to the side". >> You still use the main LLDB CLI for interaction with the debugger, voltron >> just spins off a background thread to send out data updates to client views >> (e.g. stack view, register view, etc). Have a look at the screenshot on the >> github page and you'll see what I mean (though the screenshot is GDB): >> https://github.com/snarez/voltron >> >> As such, it does not control everything that goes into and comes out of the >> CLI, so parsing the output isn't an option. >> >> Loukas >> >> On 10/10/2013, at 3:36 AM, "Yin Ma" <[email protected]> wrote: >> >>> Hi Loukas, >>> >>> We are also developing a terminal-based GUI for lldb. Our >>> Approach is to check the output from lldb to detect >>> The status change. So far it seems working fine. >>> Could you let me know why you use listener approach? >>> Do you get any case that parsing output doesn't work? >>> >>> Thanks, >>> >>> Yin >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >>> Behalf Of Malea, Daniel >>> Sent: Wednesday, October 09, 2013 8:20 AM >>> To: [email protected]; [email protected] >>> Cc: Redmond, Paul >>> Subject: Re: [lldb-dev] Python API >>> >>> Hi Loukas, >>> >>> I too have been working on a terminal UI for LLDB (but not GDB) with some >>> colleagues (CC'd). I will commit what we have thus far shortly and you can >>> see what we did, and maybe share some efforts/ideas. >>> >>> BTW, in terms of listeners, we initialize them like so: >>> >>> self.listener = debugger.GetListener() >>> >>> self.listener.StartListeningForEventClass(self.debugger, >>> lldb.SBTarget.GetBroadcasterClassName(), >>> | lldb.SBTarget.eBroadcastBitBreakpointChanged >>> | lldb.SBTarget.eBroadcastBitWatchpointChanged >>> ) >>> >>> self.listener.StartListeningForEventClass(self.debugger, >>> >>> lldb.SBThread.GetBroadcasterClassName(), >>> >>> lldb.SBThread.eBroadcastBitStackChanged >>> | lldb.SBThread.eBroadcastBitThreadSuspended >>> | lldb.SBThread.eBroadcastBitThreadResumed >>> | lldb.SBThread.eBroadcastBitSelectedFrameChanged >>> | lldb.SBThread.eBroadcastBitThreadSelected >>> ) >>> >>> self.listener.StartListeningForEventClass(self.debugger, >>> lldb.SBProcess.GetBroadcasterClassName(), >>> lldb.SBProcess.eBroadcastBitStateChanged >>> | lldb.SBProcess.eBroadcastBitInterrupt >>> | lldb.SBProcess.eBroadcastBitSTDOUT >>> | lldb.SBProcess.eBroadcastBitSTDERR >>> | lldb.SBProcess.eBroadcastBitProfileData >>> ) >>> self.listener.StartListeningForEventClass(self.debugger, >>> lldb.SBCommandInterpreter.GetBroadcasterClass(), >>> lldb.SBCommandInterpreter.eBroadcastBitThreadShouldExit >>> | lldb.SBCommandInterpreter.eBroadcastBitResetPrompt >>> | lldb.SBCommandInterpreter.eBroadcastBitQuitCommandReceived >>> | lldb.SBCommandInterpreter.eBroadcastBitAsynchronousOutputData >>> | lldb.SBCommandInterpreter.eBroadcastBitAsynchronousErrorData >>> ) >>> >>> >>> >>> >>> Cheers, >>> Dan >>> >>> >>> >>> On 2013-10-09 10:13 AM, "[email protected]" <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> I've been working on a terminal-based UI for LLDB (and GDB)[1] recently >>>> and I have a few questions about the Python API. >>>> >>>> The way this tool works currently is by registering a new command that >>>> sends updates to client views, and then registering a stop-hook that >>>> calls that command whenever the debugger stops. >>>> >>>> From looking at the sample python code and the LLDB source I think maybe >>>> I could do the same thing using SBListener/SBBroadcaster/etc. >>>> >>>> I've tried stuff like this: >>>> >>>> listener = lldb.SBListener() >>>> listener.StartListeningForEventClass(lldb.debugger, 'lldb.process', >>>> 0xffffffff) >>>> while 1: >>>> if listener.WaitForEvent(1, event): >>>> print('got event: ' + event.GetDataFlavor()) >>>> >>>> But I don't get notifications for processes starting and stopping. >>>> >>>> I've also tried stealing lldb.debugger's listener: >>>> >>>> listener = lldb.debugger.GetListener() >>>> >>>> Š but that hangs when I get the first event. I suspect maybe that's a >>>> terrible idea, and not how it's meant to be done when the LLDB CLI has >>>> created the SBDebugger instance and its listener. >>>> >>>> Is it possible to do this from a script run within an existing LLDB >>>> instance? It seems like all the sample code doing things like this is >>>> actually instantiating the SBDebugger itself and fully automating the >>>> debugging session, rather than being imported into LLDB and running from >>>> there. >>>> >>>> I'd also like to receive notifications for the following events: >>>> - a new file being loaded >>>> - a target being run >>>> - a target exiting >>>> >>>> Thanks, >>>> Loukas >>>> >>>> [1] https://github.com/snarez/voltron >>>> >>>> >>>> _______________________________________________ >>>> lldb-dev mailing list >>>> [email protected] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >>> >>> _______________________________________________ >>> lldb-dev mailing list >>> [email protected] >>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >>> >> >> >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
