gdbarch: ABFD no longer available at gdbarch_update_p time

gdbarch: ABFD no longer available at gdbarch_update_p time

[Daniel Jacobowitz]

I'm trying to add a ``set mips abi'' as we discussed earlier.  I can't find
a way to do it.  The way CRIS does this sort of thing is patently wrong (for
MIPS at least, if not for CRIS also):

      /* Update the current architecture, if needed.  */
      gdbarch_info_init (&info);
      if (!gdbarch_update_p (info))
        internal_error (__FILE__, __LINE__, "cris_gdbarch_update: failed to update architecture.");

That builds a new architecture based entirely on the defaults.  info.abfd is
gone at that point, and that's how MIPS makes lots of its decisions.  OSABI
support makes this even more pronounced.  I'd like to do:
	gdbarch_info_init_current (&info);
but since architectures have an independent lifetime from BFD objects it's
not clear how I can implement that.  Thoughts?



-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: gdbarch: ABFD no longer available at gdbarch_update_p time

[Andrew Cagney]

> I'm trying to add a ``set mips abi'' as we discussed earlier.  I can't find
> a way to do it.  The way CRIS does this sort of thing is patently wrong (for
> MIPS at least, if not for CRIS also):

Interesting, especially given the CRIS target implements it correctly :-)

>       /* Update the current architecture, if needed.  */
>       gdbarch_info_init (&info);
>       if (!gdbarch_update_p (info))
>         internal_error (__FILE__, __LINE__, "cris_gdbarch_update: failed to update architecture.");


The sequence is:

- global option is set
- architecture update is forced
-- architecture variant identified (using info, globals, and the last 
architecture)
-- existing architectures searched, if match return
-- if none match, a new architecture is created using the specified 
information

> That builds a new architecture based entirely on the defaults.  info.abfd is
> gone at that point, and that's how MIPS makes lots of its decisions.  OSABI
> support makes this even more pronounced.  I'd like to do:
> 	gdbarch_info_init_current (&info);
> but since architectures have an independent lifetime from BFD objects it's
> not clear how I can implement that.  Thoughts?

Yes, look at cris_gdbarch_init():

   else if (arches != NULL)
     {
       /* No bfd available.  Stick with the ABI from the most recently
          selected architecture of this same family (the head of arches
          always points to this).  (This is to avoid changing the ABI
          when the user updates the architecture with the 'set
          cris-version' command.)  */
       cris_abi = gdbarch_tdep (arches->gdbarch)->cris_abi;
     }
   else


Andrew

Re: gdbarch: ABFD no longer available at gdbarch_update_p time

[Daniel Jacobowitz]

On Thu, Jun 13, 2002 at 12:17:59PM -0400, Andrew Cagney wrote:
> >I'm trying to add a ``set mips abi'' as we discussed earlier.  I can't find
> >a way to do it.  The way CRIS does this sort of thing is patently wrong 
> >(for
> >MIPS at least, if not for CRIS also):
> 
> Interesting, especially given the CRIS target implements it correctly :-)

OK, I think I see where I misunderstood.

>
> >      /* Update the current architecture, if needed.  */
> >      gdbarch_info_init (&info);
> >      if (!gdbarch_update_p (info))
> >        internal_error (__FILE__, __LINE__, "cris_gdbarch_update: failed 
> >        to update architecture.");
> 
> 
> The sequence is:
> 
> - global option is set
> - architecture update is forced
> -- architecture variant identified (using info, globals, and the last 
> architecture)

This bit I'm a bit fuzzy on.  Isn't the point that the last
architecture might someday be CRIS - in 'set mips abi'?  Oh, from the
comment below it looks like you mean "the last architecture of this
family".  OK.

> -- existing architectures searched, if match return
> -- if none match, a new architecture is created using the specified 
> information
> 
> >That builds a new architecture based entirely on the defaults.  info.abfd 
> >is
> >gone at that point, and that's how MIPS makes lots of its decisions.  OSABI
> >support makes this even more pronounced.  I'd like to do:
> >	gdbarch_info_init_current (&info);
> >but since architectures have an independent lifetime from BFD objects it's
> >not clear how I can implement that.  Thoughts?
> 
> Yes, look at cris_gdbarch_init():
> 
>   else if (arches != NULL)
>     {
>       /* No bfd available.  Stick with the ABI from the most recently
>          selected architecture of this same family (the head of arches
>          always points to this).  (This is to avoid changing the ABI
>          when the user updates the architecture with the 'set
>          cris-version' command.)  */
>       cris_abi = gdbarch_tdep (arches->gdbarch)->cris_abi;
>     }
>   else

For MIPS this means that I'm going to have to carry over:
  osabi
  some ABI information which may not be available, but I could probably
save.

The latter would be the case for 'set mips abi auto', if the binary had
been loaded under 'set mips abi o32'.  We no longer know what the
binary's ABI is but that is easy to fix.

Am I on track now?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: gdbarch: ABFD no longer available at gdbarch_update_p time

[Andrew Cagney]

> - global option is set
>> - architecture update is forced
>> -- architecture variant identified (using info, globals, and the last 
>> architecture)
> 
> 
> This bit I'm a bit fuzzy on.  Isn't the point that the last
> architecture might someday be CRIS - in 'set mips abi'?

It was the case - current_gdbarch could have been pointing to CRIS when 
you were selecting MIPS.

Two things changed:

- current_gdbarch is now set to NULL during an architecture update (so 
that can't be used)
- arches is kept sorted with most recently selected always at the front 
so that arches->gdbarch is ...

 >  Oh, from the
 > comment below it looks like you mean "the last architecture of this
 > family".  OK.

Yes.

> For MIPS this means that I'm going to have to carry over:
>   osabi
>   some ABI information which may not be available, but I could probably
> save.
> 
> The latter would be the case for 'set mips abi auto', if the binary had
> been loaded under 'set mips abi o32'.  We no longer know what the
> binary's ABI is but that is easy to fix.

Ah, yes, good point.  The abi from the binary and the one that was selected.

Andrew