[lldb-dev] Python API

snare at ho.ax snare at ho.ax
Wed Oct 9 10:22:25 PDT 2013 

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, jingham at apple.com 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, snare at ho.ax 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" <yin at affinic.com> 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: lldb-dev-bounces at cs.uiuc.edu [mailto:lldb-dev-bounces at cs.uiuc.edu] On Behalf Of Malea, Daniel
>>> Sent: Wednesday, October 09, 2013 8:20 AM
>>> To: snare at ho.ax; lldb-dev at cs.uiuc.edu
>>> 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, "snare at ho.ax" <snare at ho.ax> 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
>>>> lldb-dev at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>> 
>>> 
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>> 
>> 
>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>

More information about the lldb-dev mailing list