From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8746 invoked by alias); 18 Jul 2002 01:32:09 -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 8737 invoked from network); 18 Jul 2002 01:32:07 -0000 Received: from unknown (HELO pizda.ninka.net) (216.101.162.242) by sources.redhat.com with SMTP; 18 Jul 2002 01:32:07 -0000 Received: from localhost (IDENT:davem@localhost.localdomain [127.0.0.1]) by pizda.ninka.net (8.9.3/8.9.3) with ESMTP id SAA16320; Wed, 17 Jul 2002 18:21:35 -0700 Date: Wed, 17 Jul 2002 20:20:00 -0000 Message-Id: <20020717.182135.118964970.davem@redhat.com> To: amodra@bigpond.net.au Cc: tot@trema.com, binutils@sources.redhat.com, gcc-bugs@gcc.gnu.org Subject: Re: Using binutils-2.12.1 on sparc64-sun-solaris2.8 to build gcc-3.1 results in relocation errors From: "David S. Miller" In-Reply-To: <20020718011351.GJ30362@bubble.sa.bigpond.net.au> References: <20020715.194414.38696473.davem@redhat.com> <20020717170650.64DAC2A45@dobra.labs.trema.com> <20020718011351.GJ30362@bubble.sa.bigpond.net.au> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-07/txt/msg00442.txt.bz2 From: Alan Modra Date: Thu, 18 Jul 2002 10:43:51 +0930 On Wed, Jul 17, 2002 at 07:06:50PM +0200, Teemu Torma wrote: > > "Call" is the only way R_SPARC_DISP32 relocations can be > > emitted. David, are you sure you don't get these reloc types in dwarf2 debug sections? 32-bit PC-relative relocations? I really doubt it :-) I did make a brain fart though, "call" is valid in several situations, PIC function calls in particular because that goes through the PLT which will be near the code itself. I still maintain that this isn't a binutils bug but rather some other problem. A repeatable testcase from the bug reporter posted here and in GNATS would be highly appreciated so that something concrete can be done about this problem. Currently we are groveling over the bug because not enough information is present. A reproducable testcase would eliminate this problem.