[lldb-dev] Thread created / exited notifications

[Pavel Labath]

Hello Bruce,

I've thought about this feature as well, but did not have the time to
implement it. My comments are inline.

On 2 July 2015 at 09:26, 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?
I think this would be useful piece of information that we should
display to the user. However, it is currently very low on my
priorities list.
On the other hand, if someone goes through the trouble of setting up
the general plumbing, i'd be happy to chip in with the linux support.

>
> 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.
Not necessarily. At least on linux we get notification on every thread
creation (and exit) and we can pass this information down quite
reliably.

>
> 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.
On linux, we get this notification every time a thread is created (see
NativeProcessLinux::MonitorSIGTRAP). However, we currently just drop
it on the floor. The tricky part here is passing this information from
the remote stub, through the gdb-remote-protocol, and all the way to
the user.

> 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?
Sounds like a plausible fall-back solution, but I don't think that is
necessary. I would expect that the debug api on any system can report
thread creation events in a reliable fashion. That's just my
expectation though...

> 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?
Yes, I think they would.