Re: Heads up, more multi-arch conversions ahead ...

[Andrew Cagney <ac131313 at cygnus dot com>]

Michael Snyder wrote:
> 
> Andrew Cagney wrote:
> >
> > Kevin Buettner wrote:
> >
> > > TARGET_ELF64 [want - see elf_locate_base() in solib.c]
> >
> > I've now several requests for this :-)  I'm just wondering if solib.c
> > should be obtaining the information direct from the BFD rather than
> > going to the target architecture.
> 
> Great idea, but how to do it?  I'm not very savvy about bfd...

Here is the theory:

http://sourceware.cygnus.com/ml/binutils/1999-11/msg00074.html

>    Date: Wed, 17 Nov 1999 09:00:02 +1100
>    From: Andrew Cagney <ac131313@cygnus.com>
> 
>    >    Perhaphs bfd_arch_bits_per_address(ABFD) is correct?
>    > 
>    > That will tell you whether the CPU uses 32 bits in an address or 64
>    > bits in an address.  It's not the same as elf32 vs. elf64, but it may
>    > be what you need to know.
> 
>    GDB encounters situtations (c.f. assorted mips targets) where the object
>    file contains 32 bit addresses but the target has a 64 bit address
>    space.  The 32 address values being implicitly zero or sign extended to
>    64 bits.  GDB needs to know what the object file format assumed (or
>    didn't in some case) is doing so that it can correctly do things like
>    compares.
> 
> I don't think there is any general purpose approach to this.  The 32
> bit MIPS targets act idiosyncratically, because we needed to support
> 64 bit MIPS processors before we supported the 64 bit MIPS ELF object
> file format.  I don't think any other target acts the way they do.
> 
> Note that you can't use bfd_arch_bits_per_address to determine the
> size of an address in a MIPS ELF object file.
> 
> BFD does know whether a target requires a 64 bit bfd_vma, which is
> about as close as I can see to what you are asking for.  However, this
> information is stored only in bfd/configure.in, in the setting of the
> shell variable target64.
> 
> For the special case of an ELF target, you can look at arch_size field
> of the size_info structure.  BFD doesn't currently provide any
> interface for other programs to look at that field.
> 
>    I also suspect that the sprintf_vma() et.al. macro's should format the
>    address according to the BFD object file address size rather than BFD64.
> 
> BFD64 defines the size of a bfd_vma, and sprintf_vma doesn't check an
> object file.  If it did, I think bfd_arch_bits_per_address would be
> the right thing to check.
> 
> Ian

	Andrew