On Fri, 2005-03-18 at 15:49, Alan Modra wrote:
> This only hides other more serious bugs in this function if bfd_vma is
> 32-bit.  For instance,

I don't see any benefit from fixing elfxx-ia64.c to work with a 32-bit
bfd_vma.  IA-64 is a true 64-bit architecture, like alpha.  There is no
32-bit subset architecture.  All IA-64 operating systems are 64-bit
operating systems that require a 64-bit bfd_vma.  This is enforced in
config.bfd.

One system, HPUX, supports an ILP32 ABI, but since this is implemented
with 64-bit operations, and uses 64-bit addresses, gdb at least needs to
be 64-bit aware, and I would argue that bfd does to.

Also, I'd like to point out that the build failures being discussed here
can not be reproduced with any IA-64 target, nor on an IA-64 host.  They
can only be reproduced on a (non-IA-64) 32-bit host using
--enable-targets=all.

If we did have a 32-bit IA-64 target, then yes, we should make a 32-bit
bfd_vma work.  But meanwhile, I think this is unwise.  It just creates
maintenance problems for the IA-64 maintainer (me), because no one will
remember that we must support a 32-bit bfd_vma.  Also, this potentially
hurts the performance of the IA-64 bfd support if we can't assume use of
64-bit operations even though this is a 64-bit target.

My attempts to look at this are hampered by the fact that I can't
actually reproduce it on any of the machines I normally use for
development. Either they are 64-bit machines, or they don't have the
right gcc versions needed to trigger the error Ben saw.

Anyways, I think the right solution is what Ian suggested, which is to
remove elf32-ia64.lo from BDF32_BACKENDS.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com