Re: [PATCH, binutils, ARM, 0/16] Add support for Armv8.1-M Mainline

[Alan Modra <amodra@gmail.com>]

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