This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] Include the LWP in thread-db's PTIDs
- From: Daniel Jacobowitz <drow at false dot org>
- To: Andrew Cagney <cagney at gnu dot org>
- Cc: gdb-patches at sources dot redhat dot com, msnyder at redhat dot com
- Date: Mon, 11 Oct 2004 11:38:39 -0400
- Subject: Re: [rfa] Include the LWP in thread-db's PTIDs
- References: <20041010213630.GA8218@nevyn.them.org> <416AA623.7080304@gnu.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