From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17513 invoked by alias); 7 Oct 2008 15:02:33 -0000 Received: (qmail 17462 invoked by uid 22791); 7 Oct 2008 15:02:31 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 07 Oct 2008 15:01:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 7515A2A96E4; Tue, 7 Oct 2008 11:01:54 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cdAOPep1PHyh; Tue, 7 Oct 2008 11:01:54 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 59CF62A96D5; Tue, 7 Oct 2008 11:01:54 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 0A11EE7ACD; Tue, 7 Oct 2008 08:01:54 -0700 (PDT) Date: Tue, 07 Oct 2008 15:02:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [RFA/commit] Add support for DEC threads on alpha-osf Message-ID: <20081007150154.GI28138@adacore.com> References: <20081007130322.GD28143@adacore.com> <200810071508.32985.pedro@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200810071508.32985.pedro@codesourcery.com> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00209.txt.bz2 Thanks for the quick feedback! > Hmmm, procfs.c. It looks weird that LWP 3 and the main process are > the same thing. If they are the same, and I haven't messed something up, > you should only see one of them. IIRC, I don't get that on solaris. How does it work (to determine whether the process and the LWP are the same)? I could probably take a look. Not sure whether I could help much, though. > ... this is an M:N configuration? It looks like it, because threads > 2,3,4 were added before the lwps 5,6,7, and the threads 2,3 show a > different frame from lwps 5,6. I am strongly suspecting that it is indeed an M:N configuration, but I don't know that for sure. The LWPs look like kernel threads (the pthreaddebug API mentions their existence). > Or, are all user threads scheduled on the main process/lwp ? Then what > the heck is thread 5 blocked on ? :-) Very simple: I don't know :). The threads library is a black box to me. Any other question? > Anyway, these are all dumb question that came to mind, because > I miss a description of DEC's thread model at the top of > dec-thread.c. Something akin to sol-thread.c, but needn't > be so extensive. :-) Yes, I miss this description too :). I searched all the headers as well as the web, and didn't find anything useful. So, my conclusion at this point is that we can only go with the suspicion that it is indeed and M:N model. There might be a bug (process thread should not show up if identical to one of the LWPs), but this is separate from my patch. I don't mind having a quick look if it's not too time-consuming. What do you think? -- Joel