From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18854 invoked by alias); 5 Mar 2003 00:52:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18734 invoked from network); 5 Mar 2003 00:52:24 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 5 Mar 2003 00:52:24 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18qP2G-0002Ut-00; Tue, 04 Mar 2003 20:53:36 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18qN8s-0002Pa-00; Tue, 04 Mar 2003 19:52:18 -0500 Date: Wed, 05 Mar 2003 00:52:00 -0000 From: Daniel Jacobowitz To: "J. Johnston" Cc: gdb@sources.redhat.com Subject: Re: gcore and nptl threads on linux Message-ID: <20030305005218.GA9222@nevyn.them.org> Mail-Followup-To: "J. Johnston" , gdb@sources.redhat.com References: <3E653983.8010005@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E653983.8010005@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00090.txt.bz2 On Tue, Mar 04, 2003 at 06:40:51PM -0500, J. Johnston wrote: > There is a problem with implementing gcore on linux with nptl thread > support. Under the linux nptl model, each thread is mapped to an > lwpid which is distinct from the pid of the process that created the > thread. > > The current linux gcore code is merging the pid with the tid into an > unsigned > long value. This works ok in the old model because the tid and pids are > only > 16-bits in length. This no longer can work because tids in the nptl model > are actually > addresses and are not restricted to 16-bits. I think this used to cause problems, too - it really should be just the lwpid, I'd think. For these cases at least. > This change would allow linux-proc.c to get the lwp where possible in a > cleaner > fashion. > > If nobody has any major objections to this proposal, I can post a patch > shortly. What do you plan to do when there is not a mapping, i.e. in an M:N environment? This interface assumes 1:1. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer