From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124346 invoked by alias); 15 May 2019 15:34:39 -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 124331 invoked by uid 89); 15 May 2019 15:34:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-12.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=rel X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 May 2019 15:34:37 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 53187374; Wed, 15 May 2019 08:34:36 -0700 (PDT) Received: from [10.2.207.62] (e107157-lin.cambridge.arm.com [10.2.207.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 899503F703; Wed, 15 May 2019 08:34:35 -0700 (PDT) Subject: Re: [PATCH, binutils, ARM, 0/16] Add support for Armv8.1-M Mainline To: Alan Modra Cc: "nickc@redhat.com" , "binutils@sourceware.org" , sudi.das@arm.com References: <9d62b2e9-80fb-1b31-2271-79ad052f8a25@arm.com> <5798f7d9-3059-98d7-8d02-9dd39adce0f6@redhat.com> <20190416015753.GQ14424@bubble.grove.modra.org> <20190416123631.GX14424@bubble.grove.modra.org> <69f33a7a-97ee-6343-fdb3-c087dbd98748@arm.com> <20190502012100.GE3195@bubble.grove.modra.org> From: "Andre Vieira (lists)" Message-ID: Date: Wed, 15 May 2019 15:34:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190502012100.GE3195@bubble.grove.modra.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00193.txt.bz2 Ping, this one still needs an OK. Cheers, Andre On 02/05/2019 02:21, Alan Modra wrote: > On Wed, May 01, 2019 at 10:32:17AM +0100, Andre Vieira (lists) wrote: >> As for the vxworks failures Alan spotted, I believe this is due to the >> relocations being treated differently, as you pointed out one uses REL and >> the other RELA. This leads to different relocation encodings. So for >> instance when a REL target encodes a relocation for 'target' it seems to do >> so with: >> A = 0 >> S = target >> >> whereas for RELA it uses: >> A = 4 >> S = target-4 > > No, this is confused. The "A" you are showing here is the value > displayed by objdump after decoding. This is completely irrelevant. > In actual fact the value of "A", the addend as per the ABI, is -4 for > both REL and RELA. "S" is the symbol, ie. "target" (there is no such > thing as S = target-4). > > For your first testcase, armv8_1-m-bf-rel.d, you expect > f0df e7ff bf 2, 00000000 <.target> > 0: R_ARM_THM_BF16 .target > If you squint at that instruction long enough, you'll see that the > instruction (split) field is indeed -4, and since addends are taken > from the instruction for REL relocations, "A" is -4. > > armv8_1-m-bf-rela.d expects > f0c0 e001 bf 2, 00000004 <.target\+0x4> > 0: R_ARM_THM_BF16 .target-0x4 > Here the instruction field is left as 0 (the value of the field > doesn't matter), and "A" of -4 is taken from the RELA relocation > addend. > > I believe the reason for the -4 addend is that ARM processors > calculate branch targets relative to the insn PC plus 4 for 4-byte > insns. So I don't have any problem with the patch itself, but wanted > to clear up any confusion in your patch explanation. Approval of the > patch will be handled by one of the ARM maintainers. >