From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22874 invoked by alias); 20 Feb 2006 19:52:22 -0000 Received: (qmail 22865 invoked by uid 22791); 20 Feb 2006 19:52:21 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Feb 2006 19:52:20 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k1KJqI3h000469 for ; Mon, 20 Feb 2006 14:52:18 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k1KJqI107121 for ; Mon, 20 Feb 2006 14:52:18 -0500 Received: from localhost.localdomain (vpn50-95.rdu.redhat.com [172.16.50.95]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id k1KJqH5G025636 for ; Mon, 20 Feb 2006 14:52:17 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with ESMTP id k1KJrdQC003148 for ; Mon, 20 Feb 2006 12:53:39 -0700 Date: Mon, 20 Feb 2006 19:52:00 -0000 From: Kevin Buettner To: gdb-patches@sources.redhat.com Subject: Re: [RFC] Add FR-V Linux core file support Message-ID: <20060220125215.3ea6cac7@ironwood.lan> In-Reply-To: <20060220153046.GD14155@nevyn.them.org> References: <20060214141016.4e2e56d8@ironwood.lan> <20060220153046.GD14155@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00378.txt.bz2 On Mon, 20 Feb 2006 10:30:46 -0500 Daniel Jacobowitz wrote: > > +/* Technically, the loadmap addresses are not part of `pr_reg' as > > + found in the elf_prstatus struct. The fields which communicate the > > + loadmap address appear (by design) immediately after `pr_reg' > > + though, and the BFD function elf32_frv_grok_prstatus() has been > > + implemented to include these fields in the register section that it > > + extracts from the core file. So, for our purposes, they may be > > + viewed as registers. */ > > + > > +#define FRV_PT_EXEC_FDPIC_LOADMAP 46 > > +#define FRV_PT_INTERP_FDPIC_LOADMAP 47 > > I assume that there can be threading on this target. That means the > regset functions could be used for libthread_db too; are there going to > be loadmaps there too? The gregset struct does not include the loadmap addresses. I considered adding them but decided against it because they'd be the same for all of the threads. There's no point in bulking up the gregset for an address which is only really needed for shared library initialization. > > @@ -421,6 +421,14 @@ frv_current_sos (void) > > struct so_list *sos_head = NULL; > > struct so_list **sos_next_ptr = &sos_head; > > > > + /* Make sure that the main executable has been relocated. Normally > > + this is done by SOLIB_CREATE_INFERIOR_HOOK(), however, this hook > > + is not run when loading core files. Rather than create a new hook, > > + we'll do it here if necessary. */ > > + if (main_executable_lm_info == 0 && core_bfd != NULL) > > + frv_relocate_main_executable (); > > + > > + /* Fetch the GOT corresponding to the main executable. */ > > mgot = main_got (); > > > > /* Locate the address of the first link map struct. */ > > Was this patch written recently, or forward ported from something a > bit older? I'm thinking 2006-01-24 here. The new post_create_inferior > is called when loading core files, and in turn calls > solib_create_inferior_hook. Yes, it was forward ported from something quite a bit older. I'll try removing that bit of code and see if it behaves correctly without it. Kevin