From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19424 invoked by alias); 3 Mar 2008 20:20:15 -0000 Received: (qmail 19413 invoked by uid 22791); 3 Mar 2008 20:20:14 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 03 Mar 2008 20:19:55 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1) with ESMTP id m23KJmdG025317; Mon, 3 Mar 2008 21:19:48 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id m23KJldk019460; Mon, 3 Mar 2008 21:19:47 +0100 (CET) Date: Mon, 03 Mar 2008 20:20:00 -0000 Message-Id: <200803032019.m23KJldk019460@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: mfouts@danger.com, gdb@sourceware.org, mchen@danger.com CC: msnyder@specifix.com In-reply-to: <1204574228.19253.570.camel@localhost.localdomain> (msnyder@specifix.com) Subject: Re: Why does gdb use its own thread ids internally rather than the ?tid from the underlying thread implementation? References: <1204574228.19253.570.camel@localhost.localdomain> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00030.txt.bz2 > From: "Michael Snyder" > 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.