From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10999 invoked by alias); 2 Mar 2011 16:36:09 -0000 Received: (qmail 10907 invoked by uid 22791); 2 Mar 2011 16:36:08 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW 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; Wed, 02 Mar 2011 16:36:03 +0000 Received: by wwe15 with SMTP id 15so154213wwe.12 for ; Wed, 02 Mar 2011 08:36:01 -0800 (PST) Received: by 10.227.143.65 with SMTP id t1mr7654084wbu.42.1299083761021; Wed, 02 Mar 2011 08:36:01 -0800 (PST) Received: from richards-thinkpad (gbibp9ph1--blueice2n1.emea.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id u9sm88472wbg.12.2011.03.02.08.35.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2011 08:35:59 -0800 (PST) From: Richard Sandiford To: Richard Earnshaw Mail-Followup-To: Richard Earnshaw ,binutils@sourceware.org, patches@linaro.org, richard.sandiford@linaro.org Cc: binutils@sourceware.org, patches@linaro.org Subject: Re: Fix assembly of Thumb pcrel LDRs against global symbols References: <1299079089.24968.14.camel@e102346-lin.cambridge.arm.com> Date: Wed, 02 Mar 2011 16:36:00 -0000 In-Reply-To: <1299079089.24968.14.camel@e102346-lin.cambridge.arm.com> (Richard Earnshaw's message of "Wed, 02 Mar 2011 15:18:09 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (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: 2011-03/txt/msg00022.txt.bz2 Richard Earnshaw writes: > On Mon, 2011-02-28 at 12:59 +0000, Richard Sandiford wrote: >> The PC-relative LDR instructions have no associated relocation, >> so even LDRs for global symbols should be resolved by the assembler. >> We currently handle this correctly for single-register ARM loads, >> but we're missing the associated relocation types for LDRD and Thumb. >> This leads to errors like: > > I'm not sure I agree with this. If I write > > .global foo > > ... > ldr r0, foo > > ... > > foo: > ... > > but then at link/load time pre-empt foo with some other definition, that > will silently leave me with the wrong answer. Yeah, I realise we normally try to do that. The point was that we already resolve these references at assembly time for ARM LDRs -- .syntax unified ldr r3,foo nop .globl foo foo: .word 0x1234 -- just not for Thumb LDRs or for (any) LDRDs. I think I'd wrongly assumed that the current ARM LDR behaviour was by design, and that we should make the other cases match. However, looking at the ABI again, I see there is a reloc (R_ARM_THM_PC12) that we can use here, but that we aren't using. So if the current ARM behaviour is wrong, then I suppose there are three bugs: - We're using a generic ARM_OFFSET_IMM fixup for ARM LDRs, which is always getting resolved by the assembler. We should generate a reloc instead for this case (but not for some other ARM_OFFSET_IMM cases). - We're using a generic T32_OFFSET_IMM fixup for Thumb LDRs, which is always triggering an error (one of the two in my message). We should generate a reloc instead (but not for some other T32_OFFSET_IMM cases). - We generate the internal error for things like: .syntax unified .thumb_func ldr r3,[r12,#foo-.] nop .globl foo foo: .word 0x1234 which AFAICS couldn't be handled by relocations. (The patch fixes this too.) That's a bit more work than I'd anticipated, and the first change might annoy some people, so I think I'd better put it to one side for now. :-) Richard