[lld] r252415 - [ELF2/AArch64] Support R_AARCH64_LDST64_ABS_LO12_NC relocation.

[Davide Italiano via llvm-commits]

On Mon, Nov 9, 2015 at 9:36 AM, Tim Northover <tnorthover at apple.com> wrote:
> Hi Davide,
>
> On 7 Nov 2015, at 20:54, Davide Italiano <davide at freebsd.org> wrote:
>> On Sat, Nov 7, 2015 at 8:45 PM, Davide Italiano via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>>> Author: davide
>>> Date: Sat Nov  7 22:45:26 2015
>>> New Revision: 252415
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=252415&view=rev
>>> Log:
>>> [ELF2/AArch64] Support R_AARCH64_LDST64_ABS_LO12_NC relocation.
>>>
>>
>> This one is a little bit unusual because it sets the ld/st immediate
>> value to the bits [11:3] of S + A or'ed with the contents.
>> It seems to not require the bits storing the immediate in
>> the instruction to be zero, as the testcase shows (in fact, they're
>> 0x3 before the relocation is applied).
>
> I’m not sure I understand this. When I assemble “ldr x28, [x27, :lo12:foo]” I get 0xf940037c. The immediate there is in bits 10-21, which are all 0. The 3 in bits 8-9 is actually part of the encoding for Rn (x27 = 0b11011). In these scaled instructions the low bits of the immediate are discarded (so x27 + 4 would be unencodable for a 64-bit load/store); maybe you forgot about that?
>
>> The spec doesn't really say anything about these bits being zero, but it seems weird to have a
>> .rela depending both on the contents and addend (Rafael noticed the
>> same in another relocation).
>
> The wording is “Set an LD/ST immediate value to bits [11:0] of X”. I take that to mean it completely overwrites the existing immediate so I’d mask it off before writing.
>
> Cheers.
>
> Tim.

You're correct, I was confused. Thanks for clarifying. I'll make sure
I'll do the
masking in my next commit.


-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare