Re: [rfa] Include the LWP in thread-db's PTIDs

[Daniel Jacobowitz <drow@false.org>]

On Mon, Oct 11, 2004 at 09:40:26PM +0200, Mark Kettenis wrote:
>    Date: Mon, 11 Oct 2004 11:26:27 -0400
>    From: Andrew Cagney <cagney@gnu.org>
> 
>    > At one time, I believe that thread-db.c was planned to support
>    > the full range of features supported by the libthread_db
>    > interface, presumably as defined by Sun's implementation.  That
>    > never panned out, and while non-1:1 support did work at one
>    > point, I don't think it has in a long while.  If it was wanted, I
>    > wouldn't re-implement it the same way.  So this patch begins the
>    > process of removing unneeded generality from thread-db.  In
>    > particular, while thread-db will still compute the TID, the
>    > mapping of threads to LWPs will be considered fixed.
> 
> I think assuming 1:1 threads is fair enough.  But Daniel, if you're
> going to do that, I'd like to ask you to rename thread-db.c into
> linux-thread.c or something like that.

How about glibc-thread-db.c?

> Anyway, in that case I think linux-thread.c should be a fairly
> lightweight layer around the normal Linux LWP-aware
> inf-ptrace.c-derived target vector.  Only use it to provide an LWP <->
> TID mapping, and perhaps an initial list of LWPs to attach, but
> nothing else.  The normal Linux target vector should in no way be
> dependent on it, such that it allows alternative threads strata on top
> of it.  Something else just would be a bad design.

What I'm wondering is how to handle new threads.  There are two
options: have the kernel report them and lin-lwp report them to
thread-db, and have thread-db discover them and tell lin-lwp to attach
to them.  The former is much nicer but see below...

Anyway, I'm wondering if there should be some other method of
communication between the native and thread strata (as opposed to
between lin-lwp and thread_db!).  I don't much want to use to_wait for
this, because the assumption in the rest of GDB is that to_wait returns
when all threads are stopped and I don't want to gratuitously stop all
threads when we receive a creation event.

> That's because we try to support every combination of a broken glibc
> and a broken kernel that we can find out there.  Well, perhaps not
> every possible combination, but certainly some broken combinations.
> Reliable threads-debugging requires reliable reporting of thread/LWP
> exits.  Otherwise we keep having problems with threads disappearing
> from beneath us, leaving us poking at nonexistent memory and
> registers.
> 
> I think we should ditch most of the buggy combinations and state that
> Linux threads debugging will only work reliably on Linux x.y.z or
> later with glibc a.b.c or later.

Unfortunately, thread creation events only work reliably in 2.6.x
kernels.  2.4.x is still in wide enough use that I think there's value
in holding on to it.  Thread exit, on the other hand, works pretty
reliably - there were a series of RH NPTL kernels which couldn't report
it properly, but it worked fine for LinuxThreads and now it works fine
for NPTL too.

-- 
Daniel Jacobowitz