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

Tim Northover via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 9 09:36:39 PST 2015


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.


More information about the llvm-commits mailing list