[lldb-dev] Thread created / exited notifications

[Jim Ingham]

On some platforms (Linux) it looks like you have no choice but stop on new thread creation in order to debug the code run in the new threads.  But on platforms where this is not necessary for debugging (Mac OS X) I would want this feature to be opt in.  One of the goals for any debugger, it seems to me, is to make "continue" run the program as much like running without the debugger as possible.  We need to stop at shared library loads in order to set new breakpoints, but other than that on OS X we don't really muck much with the process when it is running flat out.

BTW, though on OS X there isn't a system-provided way to learn of new thread creation, lldb has code to do this job by hand - by setting breakpoints on the two "thread start" routines that the system uses.  I use these when running functions, so that we can enforce the "run only one thread" policy when either the function being run or the system in its wisdom decides to add threads to the program.  We don't do thread destruction because there wasn't a real reason for doing it, but that could probably also be done with an appropriate breakpoint on the way out of these routines.  But again, I'm not sure how useful this is in normal practice.

I would not be in favor of batch sending of new thread creation events on stop if you can't get live tracking of thread creation & destruction.  It serves no useful purpose, since it is information you can easily gather yourself, and it gives the impression that you are getting accurate information beyond this simple calculation, which you aren't.

Jim


> On Jul 2, 2015, at 1:26 AM, Bruce Mitchener <bruce.mitchener at gmail.com> wrote:
> 
> I was hoping that I could get events for threads being created and exiting.
> 
> Right now, it looks like this is sitting on top of a mountain of various issues. So, I'm hoping that I can go through some of the steps involved to see if I'm on track.
> 
> First up, is this something that would be useful to have?
> 
> It looks like that you basically have to get the current thread list when the process stops, and see how it differs from the last time you saw the thread list.  This means that you miss out on any threads that were created and destroyed in between process stops.
> 
> One issue is platform availability for this information:
> 
> 	• Windows: information about thread creation and destruction is provided directly by the Windows debug events. Right now, it is queued up and not processed until process stops though to maintain the current thread list.
> 	• Linux: it looks like you have to use thread_db, if it is available. (For example, if someone's using musl libc, there is no equivalent functionality.) Thread lists are gotten via enumerating /proc/%d/task.
> 	• Mac OS X and iOS: it looks like this information is not available. Thread lists are gotten by calling Mach's task_threads.
> 	• FreeBSD: there's a thread_db, but this isn't currently used. Right now, thread lists are gotten via PT_GETLWPLIST via ptrace.
> 
> LLDB/MI provides this information using async records:
> 
> 	• =thread-created,id="id",group-id="gid"
> 	• =thread-exited,id="id",group-id="gid"A thread either was created, or has exited. The id field contains the gdb identifier of the thread. The gid field identifies the thread group this thread belongs to. 
> 
> So, looking at what we might need to do in LLDB:
> 
> 	• We'd have a ThreadEventData.
> 	• We'd have an SBThread::GetThreadFromEvent().
> 	• For Targets where the stub supports these events, they would issue them as an asynchronous notification.
> 		• This asynchronous notification would get broadcast as an event.
> 	• For targets where the stub doesn't support these, then perhaps some (new?) code in Process::UpdateThreadListIfNeeded() could broadcast created / exited events?
> 	• LLDB/MI could be updated to use the new events.
> 	• The GDB RSP support needs to be updated to handle the new event. It isn't clear whether or not this is supported by GDB or if this would be an LLDB extension. (The GDB docs don't mention this.)
> 	• Perhaps methods on SBProcess to allow OperatingSystem plugins to issue created / exited events.
> 
> Some questions:
> 
> 	• First up, again, should we support thread creation / exit events?
> 	• When the target doesn't provide this information, is it okay for them to be batched up as described above by diffing the thread list when updating the thread list?
> 	• If non-stop mode starts to work, how would the current model work where we just update a thread list at specific points in time? Wouldn't thread creation / exit events be more appropriate at that point?
> 	• Any thoughts on how this might work or integrate with the Operating System plugin interface? (Right now, this is all about UpdateThreadList and doesn't seem to provide a means for doing asynchronous notification like calling a method on SBProcess to create / exit threads...)
> 	• If extensions are made, is there anything for communicating this clearly to other people implementing things, like Facebook's ds2?
> 
> It took about 10 hours to track through everything and read the relevant docs and look at other implementations (like Facebook's ds2) to get a better idea for what's going on in various areas here, but I may well have gotten something wrong ... so any corrections are welcome. :)
> 
>  - Bruce
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev