From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18755 invoked by alias); 19 Mar 2005 01:05:05 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 18650 invoked from network); 19 Mar 2005 01:04:57 -0000 Received: from unknown (HELO bluesmobile.specifixinc.com) (64.220.152.98) by sourceware.org with SMTP; 19 Mar 2005 01:04:57 -0000 Received: from [127.0.0.1] (bluesmobile.corp.specifixinc.com [192.168.1.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 2B188167EA; Fri, 18 Mar 2005 17:04:57 -0800 (PST) Subject: Re: build failure for ia64 (due to -Werror) From: James E Wilson To: Andreas Schwab Cc: Nick Clifton , Ben Elliston , binutils@sources.redhat.com In-Reply-To: References: <423A2ADB.6090807@au.ibm.com> <423ABA6A.4030409@redhat.com> <20050318122113.GY21148@bubble.modra.org> <1111177693.9897.18.camel@aretha.corp.specifixinc.com> <20050318234920.GE21148@bubble.modra.org> Content-Type: text/plain Message-Id: <1111194296.9897.158.camel@aretha.corp.specifixinc.com> Mime-Version: 1.0 Date: Sat, 19 Mar 2005 04:04:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-03/txt/msg00566.txt.bz2 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