[llvm-bugs] [Bug 40357] New: Add support for R_AARCH64_LD64_GOTPAGE_LO15 relocation

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=40357

            Bug ID: 40357
           Summary: Add support for R_AARCH64_LD64_GOTPAGE_LO15 relocation
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: peter.smith at linaro.org
                CC: llvm-bugs at lists.llvm.org, peter.smith at linaro.org

This relocation is not currently supported in LLD. GCC can generate this
relocation when compiling -fpie. For example:

int ii;

void f(void) {
    int* i = ⅈ
}

At -O0 
generates:
        .comm   ii,4,4
        .text
        .align  2
        .global f
        .type   f, %function
f:
        sub     sp, sp, #16
        adrp    x0, _GLOBAL_OFFSET_TABLE_
        ldr     x0, [x0, #:gotpage_lo15:ii]
        str     x0, [sp, 8]
        nop
        add     sp, sp, 16
        ret

The :gotpage_lo15:ii generates the relocation R_AARCH64_LD64_GOTPAGE_LO15 which
evaluates to "Address of GotSlot containing address of ii" - "Address of page
containing start of GOT (x0 after the adrp X), _GLOBAL_OFFSET_TABLE_ above".

Curiously clang generates:
        .globl  f                       // -- Begin function f
        .p2align        2
        .type   f, at function
f:                                      // @f
// %bb.0:                               // %entry
        sub     sp, sp, #16             // =16
        adrp    x8, ii
        add     x8, x8, :lo12:ii
        str     x8, [sp, #8]
        add     sp, sp, #16             // =16
        ret
.Lfunc_end0:
        .size   f, .Lfunc_end0-f
                                        // -- End function
        .type   ii, at object              // @ii
        .comm   ii,4,4

Note that the address of ii is computed relative to the place and does not go
via the .got. This saves a dynamic relocation but seems to be causing some
problems with ifunc pointer equivalence. Will need to investigate that further
in a separate pr.

Reference: ELF for the 64-bit ARM Architecture for definition of relocation.
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056c/IHI0056C_beta_aaelf64.pdf

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190117/aab46d51/attachment.html>