This is the mail archive of the
mailing list for the GDB project.
Re: Test for 32/64 bit object file?
Ian Lance Taylor wrote:
> Date: Wed, 17 Nov 1999 09:00:02 +1100
> From: Andrew Cagney <email@example.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
> 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
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.