Re: Test for 32/64 bit object file?

[Andrew Cagney <ac131313 at cygnus dot com>]

Ian Lance Taylor wrote:
> 
>    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.

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

For the mips GDB could always handle that as a special case:

	o	for an elf target check the elf info

	o	for other targets just assume
		bfd_arch_bits_per_address() is correct

> Note that you can't use bfd_arch_bits_per_address to determine the
> size of an address in a MIPS ELF object file.

per above, what about for non-mips targets?

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

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

True.

	enjoy,
		Andrew