Re: Test for 32/64 bit object file?

[Andrew Cagney <ac131313 at cygnus dot com>]

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

OK, initially GDB should do this. (With big comments saying that it
could get it wrong :-).

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

And this should be done if the problem turns out to be more serious.

	Andrew