public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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 \

  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).