[lldb-dev] C++ API question

jingham at apple.com jingham at apple.com
Wed May 29 17:52:05 PDT 2013

lldb will create its own threads to handle the internal parts of the process handling, so you don't need to worry about colliding with them.  

We don't support more than one "Listener" listening to events from a given process.  We should be able to make that work in the future, but right now it just confuses us.

One listener can handle events from more than one process, if you want to do it that way, however.  If you don't supply a listener when you create a process then all the events go to the Debugger's Listener - which you can get with SBDebugger.GetListener().  

Or you can create each process with a dedicated listener, in which case you'll need to have a listening thread on your end for each process.

One other thing to consider is that each SBDebugger has one "console command interpreter".  So if you want to make it seem like there is a one to one correspondence between "process" and "command interpreter" then you will need to make a new SBDebugger to handle each process.  OTOH, if you want the console interpreter to be shared across multiple processes, you can make one SBDebugger and create multiple targets and processes in it.


On May 29, 2013, at 5:40 PM, Sebastien Metrot <meeloo at gmail.com> wrote:

> Indeed, I didn't know there was a Sync/Async switch and now it makes sense. I wanted to experiment before writing the full event system. I'll do that now. 
> Can I handle the event loop from any thread or is there something special I should be aware of concerning the API and threading?
> Thanks!
> S.
> -- 
> Sebastien Metrot
> Yasound - CTO - Cofounder
> sebastien at yasound.com
> On May 30, 2013, at 02:24 , jingham at apple.com wrote:
>> On May 29, 2013, at 5:18 PM, Enrico Granata <egranata at apple.com> wrote:
>>> Are you in synchronous mode?
>>> If not, or if you are not sure what the question even means, you most probably are not.
>>> The way LLDB works is an event system. You tell your process to run and that spawns a series of events. Events that you have to consume.
>>> You tell your process to stop, and when it stops, you get an event that tells you so.
>>> Anything until then, process is NOT stopped, and that's why you get errors saying "process is running", because you have yet to see the stop event and consume it.
>>> If you want an example of how to setup an automated interaction with LLDB, part of your checkout should be an LLDBPerf project
>>> Look around in TestCase.cpp there (http://llvm.org/svn/llvm-project/lldb/trunk/tools/lldb-perf/lib/TestCase.cpp) - the Loop() method implements a state machine that correctly consumes the events - that might be a good starting point.
>>> To keep it really simple if you're just prototyping, SBDebugger::SetAsync(false) will set LLDB in synchronous mode. In this mode of operation, the API calls consume the events before returning, and relieve you of that duty - I am not sure how complete and reliable the synchronous mode is, since we do not use it.
>> I wouldn't spend any time playing with the synchronous mode, since the process has other interesting events (in particular I/O when you are debugging remotely) that you will want to receive, and you'll need to be consuming events to get that.
>> Jim
>>> On May 29, 2013, at 5:07 PM, Sebastien Metrot <meeloo at gmail.com> wrote:
>>>> Hello,
>>>> Now that my build problems are fixed I have started to do a little more than extracting symbols from OSX applications and I have a strange situation. 
>>>> I create a target, add a symbolic breakpoint on 'main', launch the process and then inspect the threads + their stack frames. What troubles me is that I correctly find 1 thread but it always says there is 0 frames, meanwhile calling the method lldb::SBThread::GetStatus(..) and displaying its results correctly shows me what I'm expecting (a stack frame with the breakpoint on my main function). I have tried to step in lldb code and from what I understand GetNumFrames & all return 0 because it says the process is still running as it is unable to get some lock/mutex.
>>>> When I enable logs for API here is what I get:
>>>> LLDB> 1369872253.995728 SBProcess(0x1250bec00)::GetNumThreads () => 1
>>>> LLDB> 1369872253.995767 SBProcess(0x1250bec00)::Stop () => SBError (0x105602010): success
>>>> LLDB> 1369872253.995790 SBProcess(0x1250bec00)::GetThreadAtIndex (index=0) => SBThread(0x110b313d0)
>>>> LLDB> 1369872253.995807 SBThread(0x110b313d0)::GetNumFrames() => error: process is running
>>>> LLDB> 1369872253.995816 SBThread(0x110b313d0)::GetNumFrames () => 0
>>>> LLDB> 1369872253.995826 SBThread(0x110b313d0)::GetStopReason() => error: process is running
>>>> LLDB> 1369872253.995833 SBThread(0x110b313d0)::GetStopReason () => invalid
>>>> LLDB> 1369872253.999252 SBThread(0x110b313d0)::GetName() => error: process is running
>>>> LLDB> 1369872253.999277 SBThread(0x110b313d0)::GetName () => NULL
>>>> I am clearly missing something here but what?
>>>> S.
>>>> -- 
>>>> Sebastien Metrot
>>>> Yasound - CTO - Cofounder
>>>> sebastien at yasound.com
>>>> _______________________________________________
>>>> 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