[lldb-dev] Python API

[snare at ho.ax]

Hi Daniel,

That sounds good, I look forward to checking it out. Thanks for the examples, this seems to work *sometimes*:

-----

from __future__ import print_function
import threading
import lldb
import time

def __lldb_init_module(debugger, dict):
    t = ListenerThread()
    t.start()

class ListenerThread (threading.Thread):
    def run(self):
        event = lldb.SBEvent()
        listener = lldb.debugger.GetListener()
        mask = lldb.SBProcess.eBroadcastBitStateChanged | lldb.SBProcess.eBroadcastBitInterrupt | lldb.SBProcess.eBroadcastBitSTDOUT | lldb.SBProcess.eBroadcastBitSTDERR | lldb.SBProcess.eBroadcastBitProfileData
        listener.StartListeningForEventClass(lldb.debugger, lldb.SBProcess.GetBroadcasterClassName(), mask)
        while 1:
            if listener.WaitForEvent(1, event):
                print('got event: ' + event.GetDataFlavor())

-------

(lldb) command script import ~/Projects/test.py
(lldb) file ~/Projects/voltron/test_x64
Current executable set to '~/Projects/voltron/test_x64' (x86_64).
(lldb) run
got event: Process::ProcessEventData
Process 8955 launched: '/Users/snare/Projects/voltron/test_x64' (x86_64)
got event: Process::ProcessEventData
got event: Process::ProcessEventData
(lldb) reg read
General Purpose Registers:
<snip>

(lldb) cProcess 8955 resuming			 <- I hit 'c' and enter here, the rendering got a bit messed up

(lldb) got event: Process::ProcessEventData

got event: EventDataBytes

^C
^C
^C

---

… but then it hangs as you can see. This time it happened just when I loaded the inferior:

(lldb) command script import ~/Projects/test.py
(lldb) file ~/Projects/voltron/test_x64
got event: EventDataBytes
^[[A^[[A^C
^C
^C
^C

----

Are you guys using this method of loading code into LLDB with `command script import` or have you written your own front end?

Cheers,
Loukas

On 10/10/2013, at 2:20 AM, "Malea, Daniel" <daniel.malea at intel.com> wrote:

> 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
>