This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Add FR-V Linux core file support
- From: Daniel Jacobowitz <drow at false dot org>
- To: Kevin Buettner <kevinb at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 20 Feb 2006 10:30:46 -0500
- Subject: Re: [RFC] Add FR-V Linux core file support
- References: <20060214141016.4e2e56d8@ironwood.lan>
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