Re: Test for 32/64 bit object file?

[Ian Lance Taylor <ian at zembu dot com>]

   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