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 12:47:58 +1100
> From: Andrew Cagney <firstname.lastname@example.org>
> > 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
> 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.