This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Test for 32/64 bit object file?

Ian Lance Taylor wrote:
>    Date: Wed, 17 Nov 1999 12:47:58 +1100
>    From: Andrew Cagney <>
>    >    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/, 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]