From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14921 invoked by alias); 5 Mar 2003 17:25:14 -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 14909 invoked from network); 5 Mar 2003 17:25:14 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 172.16.49.205 with SMTP; 5 Mar 2003 17:25:14 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18qeX4-0003sB-00; Wed, 05 Mar 2003 13:26:26 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18qcdj-0001BW-00; Wed, 05 Mar 2003 12:25:11 -0500 Date: Wed, 05 Mar 2003 17:25:00 -0000 From: Daniel Jacobowitz To: "J. Johnston" Cc: gdb@sources.redhat.com Subject: Re: gcore and nptl threads on linux Message-ID: <20030305172511.GB4425@nevyn.them.org> Mail-Followup-To: "J. Johnston" , gdb@sources.redhat.com References: <3E653983.8010005@redhat.com> <20030305005218.GA9222@nevyn.them.org> <3E662E68.7010205@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E662E68.7010205@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00104.txt.bz2 On Wed, Mar 05, 2003 at 12:05:44PM -0500, J. Johnston wrote: > > > Daniel Jacobowitz wrote: > >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. > > > > I would think the null_ptid would serve in such a case. I guess the issue is that we should be dumping the set of LWPs to the generated core file, not the set of threads. It seems to me like GDB should be aware of the list of LWPs, and it shouldn't be hidden in each individual thread package. I may be alone in that opinion though. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer