Re: [RFC] Add FR-V Linux core file support

[Kevin Buettner <kevinb@redhat.com>]

On Mon, 20 Feb 2006 10:30:46 -0500
Daniel Jacobowitz <drow@false.org> 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