public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: James E Wilson <wilson@specifixinc.com>
To: Andreas Schwab <schwab@suse.de>
Cc: 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: Sat, 19 Mar 2005 04:04:00 -0000	[thread overview]
Message-ID: <1111194296.9897.158.camel@aretha.corp.specifixinc.com> (raw)
In-Reply-To: <jek6o47akz.fsf@sykes.suse.de>

On Fri, 2005-03-18 at 16:17, Andreas Schwab wrote:
> Ok, this is broken too.  I've reviewed all uses of bfd_vma and came up
> with this patch.  I think that should cover all those problems.  Maybe we
> should even dump ia64_insn and use bfd_uint64_t throughout instead?

You missed the point.  First of all, there is no bfd_uint64_t type when
there is no 64-bit BFD.  Secondly, all bfd_get_64 calls will fail when
there is no 64-bit BFD.  They call BFD_FAIL() in this case.  So all
bfd_get_64 calls need to be replaced with bfd_get_32 calls, and likewise
for other related functions, bfd_put_64, bfd_getl64, bfd_putl64, etc. 
Also, all long long constants (search for LL) will need to be removed. 
We can not have any uses of any 64-bit integer type at all.  There is
quite a bit of rewriting to make this all work, and we will need to
remember not to accidentally reintroduce any 64-bit code in the future. 
See for instance the elfNN_ia64_relax_brl change that Alan made last
month.

I think this is all pointless.  The elf32_ia64 vectors in config.bfd are
already protected by BFD64.  I think the problem is just what Ian
pointed out, which is that elf32-ia64.c is misclassified as a 32-bit
target in BFD32_BACKENDS etc.  It really is a 64-bit target that
generates 32-bit code, and requires a 64-bit BFD.  Hence the proper
solution is to stop compiling it on 32-bit hosts without long long. 
(Note: bfd assumes no long long is needed when --enable-targets=all is
used, unless you use --enable-64-bit-bfd.)

There are no changes needed in elfxx-ia64.c, not even the obvious one
that you already checked in, nor the one that Alan made last month, nor
the one you just proposed.

The only change we need here is a Makefile.am change.

But first I need to figure out how this stuff works.  All 3 machines on
my desk are 64-bit machines (even the embedded one), so I need to try
doing a build elsewhere.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


  reply	other threads:[~2005-03-19  1:05 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 [this message]
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
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=1111194296.9897.158.camel@aretha.corp.specifixinc.com \
    --to=wilson@specifixinc.com \
    --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).