[lldb-dev] Thread debugging (thread_db interface?)

[Greg Clayton]

On Jun 29, 2010, at 6:17 AM, Kevin Pouget wrote:

> Hi, thank you for your answer,
> 
> indeed I'm more interested by Linux, but also Unixs. Do you mean that
> there is no Thread_db at all on OSX?( I tried to check it on GDB, but
> one year after my last investigation, I can't really find my in the
> code anymore ...)

I don't believe there is.

> I guess it consequently means that there is no way that you can be
> able to debug user or hybrid level thread libraries, as it requires an
> communication with an external debug module living in the debugee
> memory space ... I'll follow the Linux porting when you'll come to
> this point!

Yes, watch the linux port for this if this is the way threads are controlled on linux. A little more clarification: when making a new debugger plug-in you subclass:

lldb_private::Process
lldb_private::Thread
lldb_private::RegisterContext

The queries for the number of threads come from pure virtual functions in lldb_private::Process and would allow the linux version to use any means to determine the current thread lists at any time, so if/when linux gets more fuctional, you will want to watch the linux subclass of lldb_private::Process for the details.

Greg Clayton

> 
> Cordially,
> 
> Kevin
> 
> On 28 Jun 2010, at 17:52, Greg Clayton <gclayton at apple.com> wrote:
> 
>> 
>> On Jun 28, 2010, at 4:08 AM, Kevin Pouget wrote:
>> 
>>> Hi,
>>> 
>>> is LLDB already able to debug multithreaded codes?
>> 
>> LLDB was build with multi-threaded debugging in mind and it can current debug multi-threaded processes. It currently does multi-threaded debugging in a process centric fashion: it suspends all other threads when one or more threads stop for any reason. Each thread knows why it stopped and maintains its own notion of what job that thread is doing: there are ThreadPlan objects that can be stacked to keep track of what each thread is doing when it comes to run control. The plans are stackable and allow you to be single stepping over a source line of code in thread 1, then hit a breakpoint in a deeper call stack (again in thread 1) and after resuming again from the second breakpoint, get back to your original stepping task.
>> 
>> We designed LLDB to be able to switch to thread centric mode where we let other threads run when others are stopped, but that is not currently the way LLDB runs and it will take some work to get it there. One big reason for this is that most of the design to date has happend on Mac OS X where we don't have a reliable way to be notified of thread creation or termination.
>> 
>> 
>>> if yes, does it (totally) rely on Thread_db to query the thread library? (could you
>>> point me to the relevant source file?)
>> 
>> No, for Mac OS X we don't currently have thread_db.h or anything like it so the Mac OS X debugger plug-in doesn't use this. Let me know if you are interested in any more specifics on the Mac OS X side, but I am guessing you are more interested in the linux side of things?
>> 
>> We have a linux port started by Eli Friedman, though I am not sure what will be used on the linux side.
>> 
>> Greg Clayton
>>