Re: NPTL libthread_db changes for static debugging

[Daniel Jacobowitz <drow at false dot org>]

On Wed, May 16, 2007 at 08:05:18PM -0700, Roland McGrath wrote:
> I think these two problems make the zero-threads interface a nonstarter.

Your version of a zero-threads approach was more aggressive about
claiming the thread ID didn't exist, since you keyed off libpthread's
initialization rather than TLS initialization, and it didn't offer a
creation event for clients to discover the first thread - I really did
go round the alternatives several times before posting my patch.  With
those I think it's feasible.

But that's not the important difference between the two patches,
anyway.  What really seems to make a difference was the nasty hack I
used to only apply the fix to static executables.  It's hard to
not change behavior in a way that confuses GDB.

> Unless this is just buggy, the only issue I see is if callers (gdb) don't
> like the th_unique and ti_tid values for the LWP changing.  If you don't
> retain info from td_thrhandle_t's after resuming from a stop, a fresh
> td_ta_thr_iter or td_ta_map_lwp2thr done later after initialization will
> have the real pointer for the initial thread.

This patch, like the other, breaks existing GDBs.  I set up a board
file which uses glibc from a separate prefix, and ran the gdb
testsuite with that and an unpatched GDB.  A number of thread lists
end up containing the main thread twice, once with its original thread
ID and once with its final thread ID.  Nothing seems to crash, though.

As for fixing upcoming GDB to work with it; GDB does cache the
td_thrhandle_t and the td_thrinfo_t, but only between stops, and the
caching may no longer be necessary now that we avoid using
libthread_db for anything we can possibly avoid it.  libthread_db is
not a particularly fast interface, and much of it can be skipped with
an assumption of 1:1 threading.  The only thing we seem to use the
handle for now is querying TLS, and the only thing we use the
td_thrinfo_t for is the TID directly after we query it.

We do query the td_thrinfo_t more often than we need to.  I'd been
meaning to cut back and cache the LWP -> TID mapping across the
lifetime of the thread, but this is somewhat complicated due to thread
death and TID reuse, so I have never yet done it.

Can we guarantee that the fake thread ID returned will always be zero
(which GDB conveniently uses to mean "not threaded" already)?  If so,
I can handle this basically the same as before, except that this time
I'll be able to enable event reporting.  But I'll need to detect a
change in thread ID for an already known LWP and delete the old
"thread".

Up to you whether the duplicate thread is acceptable for every
released GDB.

-- 
Daniel Jacobowitz
CodeSourcery