From: James E Wilson <wilson@specifixinc.com>
To: Alan Modra <amodra@bigpond.net.au>
Cc: Andreas Schwab <schwab@suse.de>, Nick Clifton <nickc@redhat.com>,
Ben Elliston <bje@au1.ibm.com>,
binutils@sources.redhat.com
Subject: Re: build failure for ia64 (due to -Werror)
Date: Wed, 23 Mar 2005 09:45:00 -0000 [thread overview]
Message-ID: <1111552545.18829.96.camel@aretha.corp.specifixinc.com> (raw)
In-Reply-To: <20050318234920.GE21148@bubble.modra.org>
[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]
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
[-- Attachment #2: patch.32-bit.ia-64 --]
[-- Type: text/plain, Size: 2352 bytes --]
2005-03-22 James E Wilson <wilson@specifixinc.com>
* Makefile.am (BFD32_BACKENDS): Delete elf32-ia64.lo.
(BFD64_BACKENDS): Add elf32-ia64.lo.
* Makefile.in: Regenerate.
Index: Makefile.am
===================================================================
RCS file: /cvs/src/src/bfd/Makefile.am,v
retrieving revision 1.149
diff -p -p -r1.149 Makefile.am
*** Makefile.am 2 Mar 2005 09:03:48 -0000 1.149
--- Makefile.am 23 Mar 2005 04:30:13 -0000
*************** BFD32_BACKENDS = \
*** 237,243 ****
elf32-i386.lo \
elf32-i860.lo \
elf32-i960.lo \
- elf32-ia64.lo \
elf32-ip2k.lo \
elf32-iq2000.lo \
elf32-m32r.lo \
--- 237,242 ----
*************** BFD32_BACKENDS_CFILES = \
*** 509,514 ****
--- 508,515 ----
# The .o files needed by all of the 64 bit vectors that are configured into
# target_vector in targets.c if configured with --enable-targets=all
# and --enable-64-bit-bfd.
+ # elf32-ia64.c requires a 64-bit bfd_vma, and hence can not be put in
+ # BFD32_BACKENDS.
BFD64_BACKENDS = \
aix5ppc-core.lo \
aout64.lo \
*************** BFD64_BACKENDS = \
*** 519,524 ****
--- 520,526 ----
elf64-x86-64.lo \
elf64-alpha.lo \
elf64-hppa.lo \
+ elf32-ia64.lo \
elf64-ia64.lo \
elf64-gen.lo \
elfn32-mips.lo \
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/bfd/Makefile.in,v
retrieving revision 1.163
diff -p -p -r1.163 Makefile.in
*** Makefile.in 2 Mar 2005 09:03:50 -0000 1.163
--- Makefile.in 23 Mar 2005 04:30:13 -0000
*************** BFD32_BACKENDS = \
*** 476,482 ****
elf32-i386.lo \
elf32-i860.lo \
elf32-i960.lo \
- elf32-ia64.lo \
elf32-ip2k.lo \
elf32-iq2000.lo \
elf32-m32r.lo \
--- 476,481 ----
*************** BFD32_BACKENDS_CFILES = \
*** 749,754 ****
--- 748,755 ----
# The .o files needed by all of the 64 bit vectors that are configured into
# target_vector in targets.c if configured with --enable-targets=all
# and --enable-64-bit-bfd.
+ # elf32-ia64.c requires a 64-bit bfd_vma, and hence can not be put in
+ # BFD32_BACKENDS.
BFD64_BACKENDS = \
aix5ppc-core.lo \
aout64.lo \
*************** BFD64_BACKENDS = \
*** 759,764 ****
--- 760,766 ----
elf64-x86-64.lo \
elf64-alpha.lo \
elf64-hppa.lo \
+ elf32-ia64.lo \
elf64-ia64.lo \
elf64-gen.lo \
elfn32-mips.lo \
next prev parent reply other threads:[~2005-03-23 4:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-18 3:58 Ben Elliston
2005-03-18 13:14 ` Nick Clifton
2005-03-18 14:13 ` Alan Modra
2005-03-18 22:15 ` James E Wilson
2005-03-18 22:49 ` Ian Lance Taylor
2005-03-18 23:31 ` Ian Lance Taylor
2005-03-18 23:52 ` James E Wilson
2005-03-18 23:37 ` Andreas Schwab
2005-03-19 0:42 ` Alan Modra
2005-03-19 1:56 ` Andreas Schwab
2005-03-19 4:04 ` James E Wilson
2005-03-19 4:30 ` Andreas Schwab
2005-03-19 9:44 ` James E Wilson
2005-03-19 12:13 ` James E Wilson
2005-03-19 17:57 ` James E Wilson
2005-03-19 18:37 ` Alan Modra
2005-03-19 18:33 ` James E Wilson
2005-03-19 19:00 ` Andreas Schwab
2005-03-23 9:45 ` James E Wilson [this message]
2005-03-23 19:24 ` Nick Clifton
2005-03-24 9:27 ` James E Wilson
2005-03-24 14:58 ` Nick Clifton
2005-03-19 0:56 ` Alan Modra
2005-03-22 2:19 ` Ben Elliston
2005-03-20 9:26 Paul Schlie
2005-03-20 19:42 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1111552545.18829.96.camel@aretha.corp.specifixinc.com \
--to=wilson@specifixinc.com \
--cc=amodra@bigpond.net.au \
--cc=binutils@sources.redhat.com \
--cc=bje@au1.ibm.com \
--cc=nickc@redhat.com \
--cc=schwab@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).