Re: Why does gdb use its own thread ids internally rather than the ?tid from the underlying thread implementation?

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> From: "Michael Snyder" <msnyder@specifix.com>
> Date: Mon, 03 Mar 2008 11:57:08 -0800
> 
> On Mon, 2008-03-03 at 10:38 -0800, Martin Fouts wrote:
> > Hi,
> > 
> > We're trying to optimize the NetBSD 4.0 implementation of pthreads,
> > which has an M:N thread implementation, and are having some trouble
> > getting gdb to work because the underlying thread id for a thread can
> > change in an M:N implementation.
> > 
> > Can anyone provide any insight into why gdb doesn't use the underlying
> > thread id?
> 
> Sure.  I think the main reason is that the underlying thread id
> is usually something awkward for a user to type (like an 8-digit
> hex number).  GDB supplies a counting number, just like for
> breakpoints, so that you can type "thread 2" instead of 
> "thread 77af21bc".
> 
> For another thing, gdb tries to present a more-or-less uniform
> user interface across platforms.  Underlying thread ids are 
> different from one platform to the next.
> 
> > Or suggestions about how to accommodate M:N without zombie queues?
> 
> Have you looked at the linux and solaris implementations?
> They both have M:N thread models.

Linux doesn't.  And even Solaris uses a 1:1 model by default nowadays.
And I really doubt the code for M:N ever worked properly in GDB.

I'm afraid that implementing GDB support for an M:N threading model is
a largely unsolved problem.

Given the fact that GDB doesn't even have support for kernel-level
threads (or LWP's) on NetBSD, I'd start with getting that working.
After that, it might be possible by implementing an additional stratum
on top of that, that does the LWP to user-level thread ID translation,
and adds in the threads that are not bound to an LWP.