This is an archive of the discontinued LLVM Phabricator instance.

[ORC] Support ADR_PREL_PG_HI21 & ADD_ABS_LO12_NC for aarch64
Needs ReviewPublic

Authored by dongAxis1944 on Jan 27 2022, 3:36 AM.

Details

Reviewers
lhames
sgraenitz
Summary

summary

This patch supports the two relocation types, R_AARCH64_ADR_PREL_PG_HI21 and R_AARCH64_ADD_ABS_LO12_NC.

Test Plan:

check-llvm

Diff Detail

Event Timeline

dongAxis1944 created this revision.Jan 27 2022, 3:36 AM
dongAxis1944 requested review of this revision.Jan 27 2022, 3:36 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 27 2022, 3:36 AM

update patch

dongAxis1944 added inline comments.Jan 27 2022, 3:45 AM
llvm/test/ExecutionEngine/JITLink/AArch64/ELF_aarch64_adrp.s
9

Hello, since I do not write raw assembly by hand, this case might be optimized.

  1. The addend of this case is 0, I do not know how to set it to the other value;
  2. The target and str are on the same page, so "decode_operand(main, 1)" is always zero, should I put the two symbols on different pages?

fix compile error

lhames added a comment.EditedJan 29 2022, 2:54 AM

Reviewing the patch as-is because I think it's a great addition. If work on the ELF/aarch64 backend is starting in earnest though I would prefer to create a new generic aarch64.h header (along the lines of riscv.h and x86_64.h) and populate it with the existing MachO relocations -- the fixup logic is generally sharable, so there shouldn't be any need to duplicate it, though ELF will probably require some extra relocations beyond the set MachO uses.

If that sounds good to you I'll try to find some time to do that next week.

llvm/lib/ExecutionEngine/JITLink/ELF_aarch64.cpp
46–48

To keep the fixup code idiomatic I would reference these values directly in each of the switch cases that use them, rather than naming them before the start of the switch.

This is particularly true for RawInstr: The fixup content isn't used for every relocation, and not all relocations are fixing up instructions.

84

Should this be RawInstr &= ~Mask?

llvm/test/ExecutionEngine/JITLink/AArch64/ELF_aarch64_adrp.s
9

This doesn't pass on my machine. Is it passing for you locally?

  1. I think you could do it by referencing an offset from str? (That's how I'd do it on MachO, but I haven't checked on ELF).
  1. You could use a fill directive to insert some filler in a way that would guarantee that str would be on a different page. That's worth testing too (both the "same page" and "different page" cases.

Your testcase doesn't actually need to run, so I'd make main separate and name each instruction to emphasize the test;

# RUN: rm -rf %t && mkdir -p %t
# RUN: llvm-mc -triple=aarch64-unknown-linux-gnu -relax-relocations=false -position-independent -filetype=obj -o %t/elf_aarch64_adrp.o %s
# RUN: llvm-jitlink -noexec -check %s %t/elf_aarch64_adrp.o

        .text

# Add a no-op main as an entry-point.
        .globl    main
        .p2align        2
main:
        ret

# Test R_AARCH64_ADR_PREL_PG_HI21
# jitlink-check: decode_operand(test_page21, 1) = str[32:12] - test_page21[32:12]
        .globl  test_page21
        .p2align        2
        .type test_page21,@function
test_page21:
        adrp    x0, str
        .size   test_page21, .-test_page21

# Test R_AARCH64_ADD_ABS_LO12_NC
# jitlink-check: decode_operand(test_pageoff12, 2) = str[11:0]
        .globl  test_pageoff12
        .p2align        2
        .type test_pageoff12,@function
test_pageoff12:
        add     x0, x0, :lo12:str
        .size   test_pageoff12, .-test_pageoff12

        .globl  str
        .type   str,@object
str:
        .asciz  "hello world"
        .size   str, 12

Reviewing the patch as-is because I think it's a great addition. If work on the ELF/aarch64 backend is starting in earnest though I would prefer to create a new generic aarch64.h header (along the lines of riscv.h and x86_64.h) and populate it with the existing MachO relocations -- the fixup logic is generally sharable, so there shouldn't be any need to duplicate it, though ELF will probably require some extra relocations beyond the set MachO uses.

If that sounds good to you I'll try to find some time to do that next week.

thanks for reviewing. I actually run the test locally, but I will rerun it again and find out the errors.

Thanks for the patch. I can't dig into the details deeper right now, but if the test issues remain I do so next week.

llvm/lib/ExecutionEngine/JITLink/ELF_aarch64.cpp
107

Unrelated change?

llvm/test/ExecutionEngine/JITLink/AArch64/ELF_aarch64_adrp.s
9

Same here. The current test is failing for me with:

Error evaluating expression 'decode_operand(main, 1) = (((str + 0) & 0xFFFFFFFFFFFFF000) - (main & 0xFFFFFFFFFFFFF000))[32:12]': Couldn't decode instruction at 'main'

I still see the same Couldn't decode instruction error with Lang's proposed test. Not sure what is the issue, but it seems related to the str operand in adrp x0, str. It doesn't show up with an immediate value like #0x1000.

Test Plan:
check-llvm

BTW from your build root you should be able to run the single test this way:

> bin/llvm-lit -vv --filter=ELF_aarch64_adrp test

Thanks for the patch. I can't dig into the details deeper right now, but if the test issues remain I do so next week.

thanks, it is wired for me. since this test just pass on my mac (T.T). I will recheck it. thanks in advance.

sunho added a subscriber: sunho.EditedMay 23 2022, 7:21 AM

@dongAxis1944 Can you still work on this? I have a fix in my local. Only few bitmask arithematic errors.

Herald added a project: Restricted Project. · View Herald TranscriptMay 23 2022, 7:21 AM
Herald added a subscriber: StephenFan. · View Herald Transcript
sgraenitz resigned from this revision.Mar 23 2023, 3:57 AM

@sunho implemented it in D126287. I think this review should be closed.