-
Notifications
You must be signed in to change notification settings - Fork 15.1k
ELF: Add support for R_AARCH64_PATCHINST relocation type. #133534
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 10 commits
9928f6e
fdcf6f4
5db4682
de0f3a2
ad4e0ff
0d90bca
a45639b
cccd109
099bf34
efb98de
41e42c0
ab863bf
fcf4206
240e141
f403ad9
7546eb8
0a100d1
988db55
4e2946f
068ad5c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| # REQUIRES: aarch64 | ||
|
|
||
| # RUN: llvm-mc -filetype=obj -triple=aarch64 %s -o %t.o | ||
| # RUN: not ld.lld %t.o -o %t 2>&1 | FileCheck --check-prefix=ERR %s | ||
|
|
||
| .rodata | ||
| # ERR: relocation R_AARCH64_FUNCINIT64 cannot be used against local symbol | ||
| .8byte func@FUNCINIT | ||
|
|
||
| .data | ||
| # ERR: relocation R_AARCH64_FUNCINIT64 cannot be used against ifunc symbol 'ifunc' | ||
| .8byte ifunc@FUNCINIT | ||
|
|
||
| .text | ||
| func: | ||
| .type ifunc, @gnu_indirect_function | ||
| ifunc: | ||
| ret |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,19 @@ | ||
| # REQUIRES: aarch64 | ||
|
|
||
| # RUN: llvm-mc -filetype=obj -triple=aarch64 %s -o %t.o | ||
| # RUN: ld.lld %t.o -o %t | ||
| # RUN: llvm-readelf -s -r %t | FileCheck %s | ||
| # RUN: ld.lld %t.o -o %t -pie | ||
| # RUN: llvm-readelf -s -r %t | FileCheck %s | ||
| # RUN: not ld.lld %t.o -o %t -shared 2>&1 | FileCheck --check-prefix=ERR %s | ||
|
|
||
| .data | ||
| # CHECK: R_AARCH64_IRELATIVE [[FOO:[0-9a-f]*]] | ||
| # ERR: relocation R_AARCH64_FUNCINIT64 cannot be used against preemptible symbol 'foo' | ||
| .8byte foo@FUNCINIT | ||
|
|
||
| .text | ||
| # CHECK: {{0*}}[[FOO]] {{.*}} foo | ||
| .globl foo | ||
| foo: | ||
| ret |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,41 @@ | ||
| # RUN: rm -rf %t && split-file %s %t | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. consider adding There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I prefer this form so that the commands are copy-pastable into the shell. |
||
| # RUN: llvm-mc -filetype=obj -triple=aarch64 %t/use.s -o %t/use-le.o | ||
| # RUN: llvm-mc -filetype=obj -triple=aarch64 %t/def.s -o %t/def-le.o | ||
|
|
||
| ## Deactivation symbol used without being defined: instruction emitted as usual. | ||
| # RUN: ld.lld -o %t/undef-le %t/use-le.o | ||
| # RUN: llvm-objdump -d %t/undef-le | FileCheck --check-prefix=UNDEF %s | ||
|
|
||
| ## Deactivation symbol defined: instructions overwritten with NOPs. | ||
| # RUN: ld.lld -o %t/def-le %t/use-le.o %t/def-le.o | ||
| # RUN: llvm-objdump -d %t/def-le | FileCheck --check-prefix=DEF %s | ||
|
|
||
| ## Behavior unchanged by endianness: relocation always written as little endian. | ||
| # RUN: llvm-mc -filetype=obj -triple=aarch64_be %t/use.s -o %t/use-be.o | ||
| # RUN: llvm-mc -filetype=obj -triple=aarch64_be %t/def.s -o %t/def-be.o | ||
| # RUN: ld.lld -o %t/undef-be %t/use-be.o | ||
| # RUN: llvm-objdump -d %t/undef-be | FileCheck --check-prefix=UNDEF %s | ||
| # RUN: ld.lld -o %t/def-be %t/use-be.o %t/def-be.o | ||
| # RUN: llvm-objdump -d %t/def-be | FileCheck --check-prefix=DEF %s | ||
|
|
||
| #--- use.s | ||
| .weak ds | ||
| # This instruction has a single relocation: the DS relocation. | ||
| # UNDEF: add x0, x1, x2 | ||
| # DEF: nop | ||
| .reloc ., R_AARCH64_PATCHINST, ds | ||
| add x0, x1, x2 | ||
| # This instruction has two relocations: the DS relocation and the JUMP26 to f1. | ||
| # Make sure that the DS relocation takes precedence. | ||
| .reloc ., R_AARCH64_PATCHINST, ds | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could be worth a test with emit-relocs to show both relocations coming out. Thinking of Bolt, which relies on emit-relocs, I expect that it would just ignore the R_AARCH_PATCHINST relocations on their own as it wouldn't know how to recreate the original value [1]. It would have to discard any relocation at the same location. We're hoping to create a binary analysis ABI supplement soon to document conventions that binary analysis tools are using. First step ARM-software/abi-aa#333 [1] In theory if we did want to let Bolt reverse a patch, the emit-relocs output could give the reverse patch. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
| # UNDEF: b {{.*}} <f1> | ||
| # DEF: nop | ||
| b f1 | ||
|
|
||
| .section .text.f1,"ax",@progbits | ||
| f1: | ||
| ret | ||
|
|
||
| #--- def.s | ||
| .globl ds | ||
| ds = 0xd503201f | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -61,6 +61,7 @@ ELF_RELOC(R_AARCH64_LD64_GOT_LO12_NC, 0x138) | |
| ELF_RELOC(R_AARCH64_LD64_GOTPAGE_LO15, 0x139) | ||
| ELF_RELOC(R_AARCH64_PLT32, 0x13a) | ||
| ELF_RELOC(R_AARCH64_GOTPCREL32, 0x13b) | ||
| ELF_RELOC(R_AARCH64_PATCHINST, 0x13c) | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also add a test to tools/llvm-readobj/ELF/reloc-types-aarch64.test There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done |
||
| // General dynamic TLS relocations | ||
| ELF_RELOC(R_AARCH64_TLSGD_ADR_PREL21, 0x200) | ||
| ELF_RELOC(R_AARCH64_TLSGD_ADR_PAGE21, 0x201) | ||
|
|
@@ -140,6 +141,7 @@ ELF_RELOC(R_AARCH64_TLS_DTPREL64, 0x405) | |
| ELF_RELOC(R_AARCH64_TLS_TPREL64, 0x406) | ||
| ELF_RELOC(R_AARCH64_TLSDESC, 0x407) | ||
| ELF_RELOC(R_AARCH64_IRELATIVE, 0x408) | ||
| ELF_RELOC(R_AARCH64_FUNCINIT64, 0x409) | ||
| // PAuthABI static and dynamic relocations: defined in pauthabielf64, | ||
| // https://github.com/ARM-software/abi-aa | ||
| ELF_RELOC(R_AARCH64_AUTH_ABS64, 0x244) | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the relocation is used as described in the RFC, with the target symbol absolute all looks well. If a non ABS symbol is used in a position independent context I think you'll get a recompile with PIC error message. If not position independent then I think the relocation will pass through and give a likely unpredictable value to patch the instruction.
Could it be worth putting some checking (likely in Relocation.cpp) to make sure the target symbol is SHN_ABS?
A related question is whether non-zero addends should be supported? For most instructions the addend doesn't make logical sense. There could be some instructions where the immediate field is in the right place to make it work, but I think these cases may not be worth supporting.
An alternative formulation for RELA is to completely ignore the symbol value and just use the bottom 32-bits of the addend field. That would give the object producer that defines the relocations more control over what is patched in. Not got a strong opinion on whether that is better though.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. getRelExpr in Arch/AArch64.cpp seems like a slightly better place since it's arch-specific semantics, so I added it there.
This could be useful for something like an hypothetical PAC variant that takes three operands like most other instructions:
meaning sign x1 using x2 and store the result in x0. Then we could encode the instruction
in the relocation addend and have the object defining the deactivation symbol define it to absolute 0. And then of course you can have the replacement instruction use whichever registers the original instruction did (or replace it entirely with NOP if the source and destination registers are the same). This doesn't seem useful for PAC given how the existing instructions work but maybe there's a non-PAC use case for this.
It doesn't seem harmful to have the flexibility of letting the instruction be defined by the symbol, the relocation or both. On the psABI issue we discussed restrictions for things like erratum fixes but for that purpose it doesn't seem to matter how the instruction word is computed. We can make it the responsibility of the object file producer(s) to ensure that the instruction formed by value+addend follows the rules.