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

[Andre Vieira (lists)]

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.
>