[PATCH, binutils, ARM, 0/16] Add support for Armv8.1-M Mainline
Andre Vieira (lists)
andre.simoesdiasvieira@arm.com
Wed May 15 15:34:00 GMT 2019
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.
>
More information about the Binutils
mailing list