This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: What does--enable-64-bit-bfd mean anyway? Thinko in bfd-in.h?
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Kai Tietz <ktietz70 at googlemail dot com>
- Cc: Dave Korn <dave dot korn dot cygwin at googlemail dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Mon, 18 May 2009 15:44:24 +0100
- Subject: Re: What does--enable-64-bit-bfd mean anyway? Thinko in bfd-in.h?
- References: <4A116DD5.3060208@gmail.com> <90baa01f0905180711p4a5f30b0x8cd471f85b81dbdc@mail.gmail.com>
Kai Tietz wrote:
> Hmm, interesting. AFAIU the switch it makes sure that bfd_vma has
> 64-bit scalar width.
Yes.
> So a absolute print of a 64-bit scalar results in
> 16 characters.
Ah, but it doesn't have to, because bfd_vma may be greater than the target
machine vma size; it's guaranteed to be at least big enough, but not to be the
exact size IIUC.
> Possile we could change the bfd_print_vma routines to
> print the upper 32-bit just in case it isn't zero. But I fear this
> could lead to other breakages, too.
Yes, I think that's probably not the right thing to do. The ideal would be
if the routines knew through what kind of target vector their callees were
invoked, maybe they should take a pointer to a BFD.
I think the simple answer might turn out to be WDDTT. I haven't looked at
the history of the option yet, but it may have only ever been intended as a
get-out-of-jail-free card for back in the old days when 64-bit int support
wasn't universal everywhere and it maybe sometimes needed to be forced on to
work round problematic autoconf tests or something like that. Using it when
BFD_ARCH_SIZE == 32 doesn't seem necessary, anyway, and setting one global
setting for all backends at configure time won't play well if you're mixing
64-bit and 32-bit targets (or indeed have only one single 32-bit target!)
cheers,
DaveK