From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31154 invoked by alias); 1 Nov 2010 11:24:06 -0000 Received: (qmail 31142 invoked by uid 22791); 1 Nov 2010 11:24:05 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Nov 2010 11:24:00 +0000 Received: by wwb39 with SMTP id 39so5310159wwb.12 for ; Mon, 01 Nov 2010 04:23:58 -0700 (PDT) Received: by 10.227.133.11 with SMTP id d11mr6569481wbt.19.1288610636887; Mon, 01 Nov 2010 04:23:56 -0700 (PDT) Received: from richards-desktop.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice2n1.emea.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id a17sm5089642wbe.0.2010.11.01.04.23.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 04:23:56 -0700 (PDT) From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" ,binutils@sourceware.org, rdsandiford@googlemail.com Cc: binutils@sourceware.org Subject: Re: [PATCH] MIPS/GAS: Fix NewABI reloc handling with the LD/SD macro References: <87wrp6m03j.fsf@firetop.home> Date: Mon, 01 Nov 2010 11:24:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Mon\, 1 Nov 2010 10\:35\:38 +0000 \(GMT\)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00004.txt.bz2 "Maciej W. Rozycki" writes: >> >> 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. I'm talking specifically about the case where no relocations are involved, i.e. where the offset is a constant integer. And yeah, the inconsistency I mentioned is precisely that uld & co. will issue a diagnostic in this case. I think that's what we should do for ld & sd as well. Richard