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

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

[Martin Fouts]

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?

Or suggestions about how to accommodate M:N without zombie queues?

Thanks,

Marty

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

[Michael Snyder]

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.

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

[Daniel Jacobowitz]

On Mon, Mar 03, 2008 at 11:57:08AM -0800, Michael Snyder wrote:
> 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.

Hopefully, Mark Kettenis will have some advice on this.  The threading
code is platform-specific, and I'm not familiar with any of the BSD ports.

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

Not any more.  Linux support for M:N was removed, since it did not
work and there were no viable M:N implementations to test with.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Mark Kettenis]

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

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

[Michael Snyder]

On Mon, 2008-03-03 at 21:19 +0100, Mark Kettenis wrote:
> > 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:
[...]
> > > 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.

Really?  It was never perfect, but I always thought of M:N on
solaris as "mostly working"...

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

Out of curiosity, how different are the thread models 
between netbsd and freebsd?  I've noticed that there
seem to be at least two different models for debugging
threads on freebsd, but I'm not up to speed on it.

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

[Mark Kettenis]

> From: Michael Snyder <msnyder@specifix.com>
> Date: Mon, 03 Mar 2008 12:37:58 -0800
> 
> On Mon, 2008-03-03 at 21:19 +0100, Mark Kettenis wrote:
> > > 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:
> [...]
> > > > 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.
> 
> Really?  It was never perfect, but I always thought of M:N on
> solaris as "mostly working"...
> 
> > 
> > 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.
> 
> Out of curiosity, how different are the thread models 
> between netbsd and freebsd?  I've noticed that there
> seem to be at least two different models for debugging
> threads on freebsd, but I'm not up to speed on it.

The code we have in GDB is for the old FreeBSD 4 userlevel threads
library, which you could call N:1 threading.  As far as I know FreeBSD
tried to do both M:N and 1:1 in FreeBSD 5, but I think M:N was more or
less abandoned because they couldn't get it to work properly.

I'm not sure what the NetBSD folks are up to these days.  Given the
history of FreeBSD, Linux and Solaris, I'd advise them to stick to
1:1, or at least get that working first before trying M:N.

OpenBSD has the beginnings of a 1:1 model, but it is not enabled by
default.  The official threads library on OpenBSD is based on the same
code as the old FreeBSD userlevel threads library (N:1).  This one is
supported by the same code in GDB.