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

[Andrew Cagney <cagney at gnu dot 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.

JeffJ's been in a constant fight with that one.

> 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).

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

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.

Andrew

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