From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128650 invoked by alias); 10 May 2017 14:06:34 -0000 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 Received: (qmail 128391 invoked by uid 89); 10 May 2017 14:06:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=nic, cae, Nic, ddi X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-it0-f54.google.com Received: from mail-it0-f54.google.com (HELO mail-it0-f54.google.com) (209.85.214.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 May 2017 14:06:30 +0000 Received: by mail-it0-f54.google.com with SMTP id o5so25324767ith.1; Wed, 10 May 2017 07:06:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RJxvCqHrxHpY8SwPxYkyBLIL7fue3QTHRJkyqMlStiA=; b=TzgtBBGTI9DoFoVcpag1ylVO4XPcQq1NYrTwIqRi94TXlviJzsFPpepRY/lxfcQwEU lhOw872roue7qs8yYIcOEwC7VL7Xp5QXQQ/vZM2EYAzN3TRD+8f9vtiTnhUXKYyv/GFz GyZ/4LrNdPGqb3jSDMNx0pz19xLh+OnDzFE2vzanraJtFxlHyp3JJlNWX0MbrXa5+RCa 4qPTfyeSUS5j9riBWg2g/LHLacrH+EsilLlkVxYC95XOWXor8nahGRGsr0cDHWEcvdmU qIz7l2k1Qi6PtYA03P7sAGWJN2KhesFQLUq9og+CjkD7DDc4FeDACXU7PCYC4JsLFHas 19PQ== X-Gm-Message-State: AODbwcCJufHi4mowBfJ2q0iaD6h+yzobnvDiIPXd7pudkyy3f9HGMFq+ X/xfeiUJ9023TTHuyZuh7NflsUQ0DWHdmX8= X-Received: by 10.36.178.1 with SMTP id u1mr5644230ite.12.1494425191268; Wed, 10 May 2017 07:06:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.181.17 with HTTP; Wed, 10 May 2017 07:06:30 -0700 (PDT) In-Reply-To: References: From: Andrew Goedhart Date: Wed, 10 May 2017 14:06:00 -0000 Message-ID: Subject: Re: [Bug ld/21458] ld generates none ARM elf ABI compliant code that causes a hard fault. To: nickc at redhat dot com Cc: binutils@sourceware.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-05/txt/msg00123.txt.bz2 Hi Nic I had a look at the programmers reference guide for the cortext M3 and M4 . I noticed that the instructions BL and B require a label not a register. This is true for ARMV4-ARMV8 architectures. All the architectures that support thumb and where a .thumb_func symbol would be relevant. Only BLX and BX can and must use a register as an operand. i.e. BLX R0 Again true from ARMV4-ARMV8. That means in thumb code you cannot branch on a register unless it is a MOV PC or BLX and BX instruction However for BLX and BX you want to set the lsb bit to 1 for a thumb target (.thumb_func). If you use a MOV, bit[0] is ignored and set to 0 so setting it to 1 does not cause failure If you are loading the address of a constant it would not be appropriate to set the lsb bit to 1 but then the target of the load would not be a STT_FUNC. or .thumb_func ARMV6T&ARMV7T -------------------------- Now for Cortext M0, M3, M4, M7 and ARMV6T Some Interesting excerpts from ARMv6 architecture [https://developer.arm.com/docs/dui0662/latest/3-the-cortex-m0-instruction-= set/35-general-data-processing-instructions/355-mov-and-mvn] Mov PC, Rx When Rd is the PC in a MOV instruction: * Bit[0] of the result is discarded. * A branch occurs to the address created by forcing bit[0] of the result to 0. The T-bit remains unmodified. for BX and BLX * The BX and BLX instructions result in a HardFault exception if bit[0] of Rm is 0. ARMV4T & ARMV5T --------------------------- Also from page A4-43 of the architecture reference manual for ARM5(T) from MOV When the PC is the destination of the instruction, a branch occurs. The instruction: MOV PC, LR can therefore be used to return from a subroutine (see instructions B, BL on page A4-10). In T variants of architecture 4 and in architecture 5 and above, the instruction BX LR must be used in place of MOV PC, LR, as the BX instruction automatically switches back to Thumb state if appropriate (but see also The T and J bits on page A2-15 for operation on non-T variants of ARM architecture version 5) also from A2-10 of the architecture reference manual: 'The precise rules depend on the current instruction set state and the architecture version: =E2=80=A2 In T variants of ARMv4 and above, including all variants of ARMv6 and above, bit[0] of a value written to R15 in Thumb state is ignored unless the instruction description says otherwise. If bit[0] of the PC is implemented (which depends on whether and how the Jazelle Extension is implemented), then zero must be written to it regardless of the value written to bit[0] of R15. =E2=80=A2 In ARMv6 and above, bits[1:0] of a value written to R15 in ARM st= ate are ignored unless the instruction description says otherwise. Bit[1] of the PC must be written as zero regardless of the value written to bit[1] of R15. If bit[0] of the PC is implemented (which depends on how the Jazelle Extension is implemented), then zero must be written to it. ' So if thumb is supported and a MOV PC, Rx is used the lsb bit is ignored on all targets upto and including V7. This means that if the target is a .thumbfunc, when doing an ADR, the lsb can be set without breaking code unless that code was loading an address for another reason other then branching to it. So if we adjusted ADR to include setting the thumb bit for targets of type /thumb_func, both .thumb_func FunctionPtr: ADR R0 FunctionPtr BLX R0 and MOV PC, R0 would function correctly. regards Andrew On Wed, May 10, 2017 at 2:10 PM, nickc at redhat dot com wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=3D21458 > > --- Comment #7 from Nick Clifton --- > (In reply to Andrew Goedhart from comment #6) > > Hi Andrew, > >> Unfortunately we may potentially have another problem. When trying to >> generate a test case I came across the following. > >> ADR R0,__testFnPtr >> BLX R0 > >> The problem is that the thumb bit is not set ( subw r0, pc, #8 >> results in an even address) and that this code causes a hard fault. >> >> Now I don't know my assembly as well as I should so there might be >> wrong/missing directives in the above file. Comment welcome > > Hmm, it appears that the ADR pseudo-instruction may not actually support > encoding thumb function addresses in the bottom bit. It is not mentioned > in the description of the instruction in the ARM ARM. (I am looking at > section A8.8.12 of the ARM DDI 0406C.b document). > > The intent, I think, is that the value loaded by an ADR instruction will > be used by a B or BL instruction, but not a BLX instruction. > > Except that there is a special case when the destination register of the > ADR instruction is the PC and the processor supports the ARMv7 ISA. > In this cae the instruction acts like a BX instruction. Prior to ARMv7 > however ADR PC,