From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21625 invoked by alias); 6 Aug 2004 20:53:40 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21612 invoked from network); 6 Aug 2004 20:53:39 -0000 Received: from unknown (HELO ns1.xcllnt.net) (209.128.86.226) by sourceware.org with SMTP; 6 Aug 2004 20:53:39 -0000 Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i76KrUHh014773; Fri, 6 Aug 2004 13:53:30 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i76KrUgF026259; Fri, 6 Aug 2004 13:53:30 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i76KrTOF026258; Fri, 6 Aug 2004 13:53:29 -0700 (PDT) (envelope-from marcel) Date: Fri, 06 Aug 2004 20:53:00 -0000 From: Marcel Moolenaar To: "Nathan J. Williams" Cc: Joel Brobecker , Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: thread ptids when debugging from core file (x86-linux) Message-ID: <20040806205329.GA25959@dhcp50.pn.xcllnt.net> References: <20040806040959.GL1192@gnat.com> <41131998.2030003@gnu.org> <20040806175818.GR1192@gnat.com> <20040806180811.GA25829@dhcp50.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-SW-Source: 2004-08/txt/msg00178.txt.bz2 On Fri, Aug 06, 2004 at 03:10:52PM -0400, Nathan J. Williams wrote: > Marcel Moolenaar writes: > > The Linux thread code (thread-db.c) already knows how to poke around > in memory and find all the threads. That memory also includes the > thread-to-LWP mapping, in some form. The trick is getting the process > callbacks in proc-service.c to look up registers of LWPs in the > matching core file section. Yes. > On Solaris and NetBSD, the .reg/NNN sections have NNN values equal to > PID + (LWPID << 16), so it's straightforward to map from a LWP to a > core section. I'm not sure how Linux names them. This doesn't work on FreeBSD and I also don't think it works on Linux. PIDs go beyond 2^16, and LWPIDs are higher numbered than PIDs on FreeBSD. I solved it on FreeBSD (which given the release schedule means that impact had to be minimal) by using the PID field in the note section to hold the LWPID and redefinition inferior_ptid in the proc_service "layer" to use the LWPID as the PID. This yielded a minimal impact for the core, inferior and remote targets as well as the ptrace(2) syscall. > It also helps to use init_thread_list() to blow away the list that > corelow.c generates. I happen to do that on FreeBSD as well, but that's mostly because of MxN threading. For unbound threads the correlation between LWPID and TID is non-constant and there's significant overhead to have the PTID include both. So, the PTID only has the TID (and of course the PID, but that's constant), which means that the thread list created by corelow, which has the LWPID in the PID field on FreeBSD, needs to be replaced by a thread list that has TID filled in. For 1xN or 1x1 threading you don't have to throw away the thread list that corelow.c creates, but the purpose of libthread_db is to abstract the difference so we don't try to avoid it :-) Anyway, to get back to Joel's original mail: a logical solution that would minimize knowledge of the threading implementation is to use the libthread_db API to access thread information, and to keep the Ada task to TID mapping inside the Ada-tasks layer. If the Ada-tasks layer is a target on top of the thread target, then it makes sense to have the thread list in GDB use Ada-tasks specific IDs. It may then even be possible to use target_beneath->[method]() without having to use the libthread_db API. Put differently, one can view the Ada-tasks layer as a 1:1 threading target on top of the threads target. Just a thought, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net