From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26973 invoked by alias); 8 Apr 2003 08:53:52 -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 26941 invoked from network); 8 Apr 2003 08:53:51 -0000 Received: from unknown (HELO mta04ps.bigpond.com) (144.135.25.136) by sources.redhat.com with SMTP; 8 Apr 2003 08:53:51 -0000 Received: from bubble.local ([144.135.25.69]) by mta04ps.bigpond.com (Netscape Messaging Server 4.15 mta04ps Jul 16 2002 22:47:55) with SMTP id HD0OPF00.4LD for ; Tue, 8 Apr 2003 18:53:39 +1000 Received: from CPE-144-136-188-60.sa.bigpond.net.au ([144.136.188.60]) by psmam01bpa.bigpond.com(MAM V3.3.2 71/2865109); 08 Apr 2003 18:53:39 Received: (qmail 13387 invoked by uid 179); 8 Apr 2003 08:53:38 -0000 Date: Tue, 08 Apr 2003 08:53:00 -0000 From: Alan Modra To: Andreas Jaeger Cc: Alexandre Oliva , Andreas Schwab , binutils@sources.redhat.com, Stefan Reinauer Subject: Re: 64bit bfd_vma vs 32bit address space in linker Message-ID: <20030408085338.GY1189@bubble.sa.bigpond.net.au> Mail-Followup-To: Andreas Jaeger , Alexandre Oliva , Andreas Schwab , binutils@sources.redhat.com, Stefan Reinauer References: <20030408005837.GU1189@bubble.sa.bigpond.net.au> <20030408051753.GW1189@bubble.sa.bigpond.net.au> <20030408064554.GX1189@bubble.sa.bigpond.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2003-04/txt/msg00203.txt.bz2 On Tue, Apr 08, 2003 at 09:28:13AM +0200, Andreas Jaeger wrote: > but where do we need to add the "currently > missing linker address wrap"? Everywhere. The primary change is to mask places that adjust "dot" in ldlang.c and ldexp.c, but this change will trickle down into all expression evaluation code. eg. an address difference on a 32 bit target like 0 - 0xffff0000 should evaluate to 0x10000 regardless of whether bfd_vma is 32-bit or 64-bit. Perhaps you see why I merely acknowledge the bug and don't jump in with a patch. :-) -- Alan Modra IBM OzLabs - Linux Technology Centre