From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26025 invoked by alias); 6 Aug 2004 19:10:57 -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 26016 invoked from network); 6 Aug 2004 19:10:56 -0000 Received: from unknown (HELO biscayne-one-station.mit.edu) (18.7.7.80) by sourceware.org with SMTP; 6 Aug 2004 19:10:56 -0000 Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i76JAsRU010490; Fri, 6 Aug 2004 15:10:54 -0400 (EDT) Received: from contents-vnder-pressvre.mit.edu (CONTENTS-VNDER-PRESSVRE.MIT.EDU [18.7.16.67]) (authenticated bits=56) (User authenticated as nathanw@ATHENA.MIT.EDU) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id i76JAroM013288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Aug 2004 15:10:53 -0400 (EDT) Received: (from nathanw@localhost) by contents-vnder-pressvre.mit.edu (8.12.9) id i76JAqA5012169; Fri, 6 Aug 2004 15:10:52 -0400 (EDT) To: Marcel Moolenaar Cc: Joel Brobecker , Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: thread ptids when debugging from core file (x86-linux) References: <20040806040959.GL1192@gnat.com> <41131998.2030003@gnu.org> <20040806175818.GR1192@gnat.com> <20040806180811.GA25829@dhcp50.pn.xcllnt.net> From: "Nathan J. Williams" Organization: Wasabi Systems, Inc. Date: Fri, 06 Aug 2004 19:10:00 -0000 In-Reply-To: <20040806180811.GA25829@dhcp50.pn.xcllnt.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-08/txt/msg00165.txt.bz2 Marcel Moolenaar writes: > On Fri, Aug 06, 2004 at 10:58:18AM -0700, Joel Brobecker wrote: > > > >I've always assumed that corelow.c's mapping between .reg sections and > > > >threads was intended as a minimal fallback. The module I wrote for > > > >NetBSD's threads (which I'll get into shape for the FSF tree Real Soon > > > >Now) punts that list and generates its own list of threads from the > > > >memory structures of libpthread in the core file, just as it would for > > > >a live process. > > > > > So do you think I'll have to dig into the inferior memory for data used > > by the libpthread library to find that information? Is this something > > that would be portable across NPTL versions? Supposing we want to go > > that route, does anybody know where to find some documentation (or some > > code) that exposes the data structures, so I can try digging into them? > > [not strictly Linux, but more genericly] > > But how do you map register contents in the various .reg/# sections to > the right thread if there's no way to correlate .reg/# sections to light- > weight processes? Would this in fact imply that the IDs needs to match? 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. Here's the getregs callback in nbsd-thread.c: nbsd_thread_proc_getregs (void *arg, int regset, int lwp, void *buf) { struct cleanup *old_chain; int ret; old_chain = save_inferior_ptid (); if (target_has_execution) { inferior_ptid = BUILD_LWP (lwp, main_ptid); child_ops.to_fetch_registers (-1); } else { inferior_ptid = pid_to_ptid ((lwp << 16) | GET_PID (main_ptid)); orig_core_ops.to_fetch_registers (-1); } ret = 0; switch (regset) { case 0: fill_gregset ((gregset_t *)buf, -1); break; case 1: fill_fpregset ((fpregset_t *)buf, -1); break; default: /* XXX need to handle other reg sets: SSE, AltiVec, etc. */ ret = TD_ERR_INVAL; } do_cleanups (old_chain); } 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. It also helps to use init_thread_list() to blow away the list that corelow.c generates. - Nathan