Add arm64 kernel support for -z ifunc-noplt

[markj]

Summary

We need to handle relocations against the immediate value of call
instructions, i.e., R_AARCH64_CALL26. For good measure I added support
for a few related relocation types.

I used the definitions provided here:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf

Test Plan

I defined a dummy ifunc and verified that a kernel linked with -zifunc-noplt contains
the expected text relocations, and that we apply them properly, e.g.:

0xffff00000069a9a0 <+0>:     stp     x22, x21, [sp, #-48]!
0xffff00000069a9a4 <+4>:     stp     x20, x19, [sp, #16]
0xffff00000069a9a8 <+8>:     stp     x29, x30, [sp, #32]
0xffff00000069a9ac <+12>:    add     x29, sp, #0x20
0xffff00000069a9b0 <+16>:    mov     x19, x3
0xffff00000069a9b4 <+20>:    mov     x20, x2
0xffff00000069a9b8 <+24>:    mov     x21, x1
0xffff00000069a9bc <+28>:    mov     x22, x0
0xffff00000069a9c0 <+32>:    bl      0xffff0000006a5088 <markjifunc_resolved>

[markj]

• Return -1 upon a lookup error, as the lookup functions return errno values. This doesn't appear to matter in practice though.

[kib]

The aarch64 ABI document (mine is called IHI0056C) is very clear about distinction between dynamic and static relocations. Our kernel and modules are the objects which were finalized in static linking, so according to the ARM requirements, they should avoid non-dynamic relocations.

I do not object against the patch, but think that it would cause more resistance than the amd64 hack.

[emaste]

think that it would cause more resistance than the amd64 hack

We do have a relationship with the Arm LLVM toolchain folks and they're relatively active, so we should be able to discuss this further with them

[markj]

In D17392#371076, @kib wrote:

The aarch64 ABI document (mine is called IHI0056C) is very clear about distinction between dynamic and static relocations. Our kernel and modules are the objects which were finalized in static linking, so according to the ARM requirements, they should avoid non-dynamic relocations.

Are you referring specifically to the text at the beginning of section 4.6, or something else? I had read that but did not interpret them as requirements, as they don't use strict verbiage ("shall", "must", etc.) seen elsewhere in the document. I also do not see any suitable dynamic relocation types - none of them are PC-relative.

[kib]

In D17392#371088, @markj wrote:

In D17392#371076, @kib wrote:

The aarch64 ABI document (mine is called IHI0056C) is very clear about distinction between dynamic and static relocations. Our kernel and modules are the objects which were finalized in static linking, so according to the ARM requirements, they should avoid non-dynamic relocations.

Are you referring specifically to the text at the beginning of section 4.6, or something else? I had read that but did not interpret them as requirements, as they don't use strict verbiage ("shall", "must", etc.) seen elsewhere in the document. I also do not see any suitable dynamic relocation types - none of them are PC-relative.

Start of 4.6 and 4.6.11. It says that dynamic linker only needs to support dynamic relocations.

[markj]

I agree that we're going against the spec here. -zifunc-noplt is a hack, but it is pretty simple from the linker's perspective, so I doubt we'll see objections from the lld developers on the basis that it violates the armv8 ABI.

[markj]

• Add a comment explaining why we handle static relocations.

[emaste]

@andrew your thoughts?

[andrew]

I'm fine with breaking from the ABI in the kernel & modules as long as it's just for optimisation and we don't require the breakage to allow the kernel to still work after being built with, for example, gcc & linked with bfd.

[markj]

In D17392#417232, @andrew wrote:

I'm fine with breaking from the ABI in the kernel & modules as long as it's just for optimisation and we don't require the breakage to allow the kernel to still work after being built with, for example, gcc & linked with bfd.

The change just expands the set of relocation types handled by the in-kernel linker. It shouldn't have impact for kernels built without -zifunc-noplt.