From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26761 invoked by alias); 20 Feb 2006 15:31:41 -0000 Received: (qmail 26747 invoked by uid 22791); 20 Feb 2006 15:31:39 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 20 Feb 2006 15:30:49 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FBCzu-0004AO-CH; Mon, 20 Feb 2006 10:30:46 -0500 Date: Mon, 20 Feb 2006 15:31:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Add FR-V Linux core file support Message-ID: <20060220153046.GD14155@nevyn.them.org> Mail-Followup-To: Kevin Buettner , gdb-patches@sources.redhat.com References: <20060214141016.4e2e56d8@ironwood.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060214141016.4e2e56d8@ironwood.lan> User-Agent: Mutt/1.5.8i 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/msg00357.txt.bz2 On Tue, Feb 14, 2006 at 02:10:16PM -0700, Kevin Buettner wrote: > The patch below adds core file support for FR-V running either > GNU/Linux or uClinux. > > The interesting part of this patch is the bit which causes the main > executable to get relocated. I thought at first that I would need to > add a new hook which does for core files what SOLIB_CREATE_INFERIOR_HOOK > does for processes, but this turned out to not be necessary. I was able > to handle the case that I care about by adding a suitable call to > frv_current_sos(). I was surprised, however, that we had (apparently) > never run into this problem before. > > Comments? Hmm, interesting. Two things poke out at me: > +/* 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? I don't much like faking registers this way, but the FRV port has prior art - this isn't new - so I won't complain too much. I'd have made them a separate target object. > @@ -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. -- Daniel Jacobowitz CodeSourcery