From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6316 invoked by alias); 5 Mar 2003 17:05:46 -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 6280 invoked from network); 5 Mar 2003 17:05:45 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 5 Mar 2003 17:05:45 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 9E53F80001E; Wed, 5 Mar 2003 12:05:44 -0500 (EST) Message-ID: <3E662E68.7010205@redhat.com> Date: Wed, 05 Mar 2003 17:05:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: gcore and nptl threads on linux References: <3E653983.8010005@redhat.com> <20030305005218.GA9222@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00100.txt.bz2 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. -- Jeff J.