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 <[email protected]> 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 >> _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
