From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41138 invoked by alias); 2 May 2019 01:21:09 -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 40862 invoked by uid 89); 2 May 2019 01:21:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:69f33a7, H*f:sk:69f33a7, H*r:sk:static., HX-HELO:sk:mail-pl X-HELO: mail-pl1-f174.google.com Received: from mail-pl1-f174.google.com (HELO mail-pl1-f174.google.com) (209.85.214.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 02 May 2019 01:21:06 +0000 Received: by mail-pl1-f174.google.com with SMTP id ck18so245379plb.1 for ; Wed, 01 May 2019 18:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=fHaVn/ZeEPa8NFBcMrKCE6tl63oJAFSNv/NWKf2vZSg=; b=QFTjFl2WkeXsc9CCNSJ23L8120Cohlmfobag7AI3WLsMOXcEfAE0/xs7ph66C8Y7Pa q0BoWtWPVJbv6wW0AVU9B2hsMZpZG7dJRtow3l9QZZ3TcId4IeMY1zZ1GIUnRTPeEvhx 33kM1ixbenYBMHvOCgyFXdFeU9EdNBhII3owIoghLCNbgVsC1FzALoNNK8khestcqbSh cH9gjGm+sq0uVkOe535C8bWXvgWph7Or4Qn+Rr0J0Lef6+Oo5e6JSZ5wKt0Pgo7Ygyie ZoGKzA9GHNQMrUdr3vMd3tEa79ojJ25UWtPmc9hS2ssScm/4YQN4EhC+wNJxttuTMvuj uOCg== Return-Path: Received: from bubble.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id t5sm51591189pfh.141.2019.05.01.18.21.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 01 May 2019 18:21:04 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 48D5A804D9; Thu, 2 May 2019 10:51:00 +0930 (ACST) Date: Thu, 02 May 2019 01:21:00 -0000 From: Alan Modra To: "Andre Vieira (lists)" Cc: "nickc@redhat.com" , "binutils@sourceware.org" , sudi.das@arm.com Subject: Re: [PATCH, binutils, ARM, 0/16] Add support for Armv8.1-M Mainline Message-ID: <20190502012100.GE3195@bubble.grove.modra.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69f33a7a-97ee-6343-fdb3-c087dbd98748@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00092.txt.bz2 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. -- Alan Modra Australia Development Lab, IBM