From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23646 invoked by alias); 4 Mar 2003 23:40:54 -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 23565 invoked from network); 4 Mar 2003 23:40:52 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 4 Mar 2003 23:40:52 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id B469F80001E for ; Tue, 4 Mar 2003 18:40:51 -0500 (EST) Message-ID: <3E653983.8010005@redhat.com> Date: Tue, 04 Mar 2003 23:40: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: gdb@sources.redhat.com Subject: gcore and nptl threads on linux Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00089.txt.bz2 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. The kernel has no knowledge of thread ids and generates the corefile prstatus notes using the lwpids. It would be cleaner if the gcore output emulated this kernel output. Now, the gcore code has access to the thread list, but at the thread layer, there is no lwp info in the list (just pid and tid info). At present, the only exposed interface for fetching the lwp from a thread ptid_t is the to_pid_to_str() target function. This converts the ptid to string form and will contain the LWP in string form. To fish this out requires parsing the output and converting string to integer. I have a working example of this, but this is considered a bit of an ugly hack. I would like to propose exposing the lwp_from_thread() functionality currently present in the existing threading code. Notably, thread-db.c has lwp_from_thread(), sol-thread.c has thread_to_lwp(), and uw-thread.c has thr_to_lwp() which are all static functions. The default version of this target function would simply return the ptid_t input to it. 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. -- Jeff J.