Re: Test for 32/64 bit object file?

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

   Date: Wed, 17 Nov 1999 12:47:58 +1100
   From: Andrew Cagney <ac131313@cygnus.com>

   >    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.

   If we consider the MIPS idiosyncratic then can
   bfd_arch_bits_per_address() be considered reliable for non mips/elf
   targets?

That will always get you the size of an address of the CPU.  There is
no particular reason to assume that that is the size of an address
stored in the object file.

I don't know of any other case where it is different.  But I'm not
going to promise that there will never be another case.

   > 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.

   I think the macro ARCH_SIZE defined/used by some targets contains what
   I'm looking for.
   Is it worth extending BFD (struct bfd_target) to include that
   information somewhere?  (Grubbing through the code it doesn't look easy
   - many changes to many files).

Yes, ARCH_SIZE is probably approximately what you are asking for.  But
it isn't used by every backend.

Ian