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

[Daniel Jacobowitz <drow@false.org>]

On Mon, Oct 11, 2004 at 11:26:27AM -0400, Andrew Cagney wrote:
> >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.
> 
> JeffJ's been in a constant fight with that one.

Yes, so have I.  I have at least two pending patches (not posted yet)
that depend on fixing this.

> >My goal is to have a GNU/Linux target vector, whose entry points call into
> >thread-db when necessary, instead of having a thread-db wrapper around all
> >the GNU/Linux methods.  One of the things this will fix is the need for two
> >separate versions of the GNU/Linux native wait() code - we will always use
> >the multi-threaded-aware version.  Another thing it will fix is a bug in 
> >the
> >fork-following code which tries to find the LWP from a thread ID.
> 
> Per the changes I've been making, yes, there needs to be a single 
> inf-linux inferior (derived from inf-ptrace?) that always has the LWP 
> code enabled(1).

Yes, I know you've been working on this.  Therefore I'm working on
something related but approaching from the opposite side - fixing the
LWP vector.  Hopefully we'll help each other instead of tripping over
each other.

> thread-db is more interesting.  As a user-level thread model, yes it is 
> GNU/Linux specific and should be consolidated - linux-nptl say?

It's not NPTL specific; the bits of thread_db we need to be using
work for both LinuxThreads and NPTL.

> However, as with many systems, GNU/Linux needs to be able to support 
> multiple user-level thread models (e.g., Ada's tasks), and be able to 
> layer each of those user-level thread models over more than just 
> inf-linux (esp corefiles).  Consequently, linux-nptl can't be folded 
> into inf-linux, and the indirection provided by the thread-stratum needs 
> to be retained.

I hadn't thought about the core issue; I'll do some pondering. However,
I don't think your comment is quite right.  Thread_db can not be
layered over core files, we've already decided that - it's too iffy to
find the right thread_db, not to mention cross-debugging issues.  And
similarly we can't use it for remote thread debugging.  Thread_db only
makes any sense on top of local, running, native threads.

If any of the higher level features of thread_db, like mutex
information, were usable on GNU/Linux, then a mode in which we
associated a local thread_db with a core file might be interesting.  But
this isn't the case today; none of that is implemented in glibc.

Ada tasks are actually a very interesting example, since IIUC they are
layered on top of POSIX threads.  Joel, have I got that right?  So if
we use a thread strata for libthread_db, we'd need two thread strata.

> (1) Have you noticed now the lin_lwp inferior uses /proc for memory 
> accesses yet the default vector does not?

Yes, I wrote that code.  I've never had time to consolidate it and this
seems like a good chance.  It was for a very specific problem which
only mattered when thread_db was in use - thread_db triggers single
reads of excessively large size.

-- 
Daniel Jacobowitz