From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22080 invoked by alias); 1 Nov 2010 10:35:47 -0000 Received: (qmail 21948 invoked by uid 22791); 1 Nov 2010 10:35:46 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from eddie.linux-mips.org (HELO cvs.linux-mips.org) (78.24.191.182) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Nov 2010 10:35:40 +0000 Received: from localhost.localdomain ([127.0.0.1]:41152 "EHLO localhost.localdomain" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S1491176Ab0KAKfi (ORCPT ); Mon, 1 Nov 2010 11:35:38 +0100 Date: Mon, 01 Nov 2010 10:35:00 -0000 From: "Maciej W. Rozycki" To: Richard Sandiford cc: binutils@sourceware.org Subject: Re: [PATCH] MIPS/GAS: Fix NewABI reloc handling with the LD/SD macro In-Reply-To: Message-ID: References: <87wrp6m03j.fsf@firetop.home> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-11/txt/msg00003.txt.bz2 On Mon, 1 Nov 2010, Richard Sandiford wrote: > >> This may be a known bug, and is certainly nothing to do with your patches, > >> but I notice: > >> > >> ld $4,0x7ffc($5) > >> > >> fails to work correctly (or trigger a diagnostic) in o32 mode. > >> 0x8000 works fine of course. > > > > You didn't like my patch addressing this issue back here: > > > > http://sourceware.org/ml/binutils/2005-02/msg00610.html > > > > (originally here: http://sourceware.org/ml/binutils/2004-06/msg00530.html) > > > > but I've kept maintaining it locally over the years (and got it up to > > 2.20; obviously with the recent changes it'll require an update, but I > > planned to do that anyway while upgrading the RPM packages I maintain). > > If you'd like me to get it refreshed and resubmitted, then I am all for > > it. > > No, I stand by what I said there. IMO the reloc case isn't interesting > for the reasons discussed in that thread. The o(b) case _is_ > interesting because it is inconsistent with the corresponding > o(b) behaviour for unaligned loads and stores. I am confused. The very purpose of that patch (binutils-*-mips-dword-reloc.patch, for the avoidance of doubt) is to avoid an overflow from 0x7ffc wrapping to -0x8000. If you're concerned about my proposal pessimising code for a corner case where one of two LO16 relocs sharing a common HI16 reloc has a carry at the link stage into the HI16 reloc while the other one does not, then perhaps it would be enough if LD just failed the link complaining about this problem instead? Then we would only have to take care of the immediate addend of 0x7ffc. The drawback is if the LD error is hit, the user would have to sort out the problem himself and frankly "rearranging code so that the symbol has its final address different to " sounds rather like a dodgy solution to me. It looks I've had that binutils-*-mips-reloc-got-offset.patch change outstanding for a couple of years too. ;) Maciej