maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/x86-64-zrel-zrela.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

59 lines
1.7 KiB
ArmAsm
Raw Normal View History

[ELF] Add -z rel and -z rela LLD supports both REL and RELA for static relocations, but emits either of REL and RELA for dynamic relocations. The relocation entry format is specified by each psABI. musl ld.so supports both REL and RELA. For such ld.so implementations, REL (.rel.dyn .rel.plt) has size benefits even if the psABI chooses RELA: sizeof(Elf64_Rel)=16 < sizeof(Elf64_Rela)=24. * COPY, GLOB_DAT and J[U]MP_SLOT always have 0 addend. A ld.so implementation does not need to read the implicit addend. REL is strictly better. * A RELATIVE has a non-zero addend. Such relocations can be packed compactly with the RELR relocation entry format, which is out of scope of this patch. * For other dynamic relocation types (e.g. symbolic relocation R_X86_64_64), a ld.so implementation needs to read the implicit addend. REL may have minor performance impact, because reading implicit addends forces random access reads instead of being able to blast out a bunch of writes while chasing the relocation array. This patch adds -z rel and -z rela to change the relocation entry format for dynamic relocations. I have tested that a -z rel produced x86-64 executable works with musl ld.so -z rela may be useful for debugging purposes on processors whose psABIs specify REL as the canonical format: addends can be easily read by a tool. Reviewed By: grimar, mcgrathr Differential Revision: https://reviews.llvm.org/D80496
2020-05-30 05:22:03 +08:00
# REQUIRES: x86
## The x86-64 psABI uses Elf64_Rela relocation entries. We produce
## Elf64_Rel dynamic relocations by default, but can use Elf64_Rel with -z rel.
# RUN: llvm-mc -filetype=obj -triple=x86_64 %s -o %t.o
# RUN: ld.lld -shared %t.o -o %t.so
# RUN: llvm-readobj -d -r %t.so | FileCheck --check-prefix=RELA %s
# RUN: ld.lld -shared -z rela %t.o -o %t1.so
# RUN: llvm-readobj -d -r %t1.so | FileCheck --check-prefix=RELA %s
# RELA: RELA {{.*}}
# RELA-NEXT: RELASZ 72 (bytes)
# RELA-NEXT: RELAENT 24 (bytes)
# RELA-NEXT: RELACOUNT 1
# RELA-NEXT: JMPREL {{.*}}
# RELA-NEXT: PLTRELSZ 24 (bytes)
# RELA-NEXT: PLTGOT {{.*}}
# RELA-NEXT: PLTREL RELA
# RELA: .rela.dyn {
# RELA-NEXT: R_X86_64_RELATIVE - 0x3428
# RELA-NEXT: R_X86_64_GLOB_DAT func 0x0
# RELA-NEXT: R_X86_64_64 _start 0x2A
# RELA-NEXT: }
# RELA-NEXT: .rela.plt {
# RELA-NEXT: R_X86_64_JUMP_SLOT func 0x0
# RELA-NEXT: }
# RUN: ld.lld -shared -z rela -z rel %t.o -o %t2.so
# RUN: llvm-readobj -d -r -x .data %t2.so | FileCheck --check-prefix=REL %s
# REL: REL {{.*}}
# REL-NEXT: RELSZ 48 (bytes)
# REL-NEXT: RELENT 16 (bytes)
# REL-NEXT: RELCOUNT 1
# REL-NEXT: JMPREL {{.*}}
# REL-NEXT: PLTRELSZ 16 (bytes)
# REL-NEXT: PLTGOT {{.*}}
# REL-NEXT: PLTREL REL{{$}}
# REL: .rel.dyn {
[llvm-readobj] - For SHT_REL relocations, don't display an addend. This is https://bugs.llvm.org/show_bug.cgi?id=44257. In LLVM style we always print `0` as addend when dumping SHT_REL relocations. It is confusing, this patch stops printing it as the first comment on the bug page suggests. Differential revision: https://reviews.llvm.org/D93033
2020-12-10 21:12:26 +08:00
# REL-NEXT: R_X86_64_RELATIVE
# REL-NEXT: R_X86_64_GLOB_DAT func
# REL-NEXT: R_X86_64_64 _start
[ELF] Add -z rel and -z rela LLD supports both REL and RELA for static relocations, but emits either of REL and RELA for dynamic relocations. The relocation entry format is specified by each psABI. musl ld.so supports both REL and RELA. For such ld.so implementations, REL (.rel.dyn .rel.plt) has size benefits even if the psABI chooses RELA: sizeof(Elf64_Rel)=16 < sizeof(Elf64_Rela)=24. * COPY, GLOB_DAT and J[U]MP_SLOT always have 0 addend. A ld.so implementation does not need to read the implicit addend. REL is strictly better. * A RELATIVE has a non-zero addend. Such relocations can be packed compactly with the RELR relocation entry format, which is out of scope of this patch. * For other dynamic relocation types (e.g. symbolic relocation R_X86_64_64), a ld.so implementation needs to read the implicit addend. REL may have minor performance impact, because reading implicit addends forces random access reads instead of being able to blast out a bunch of writes while chasing the relocation array. This patch adds -z rel and -z rela to change the relocation entry format for dynamic relocations. I have tested that a -z rel produced x86-64 executable works with musl ld.so -z rela may be useful for debugging purposes on processors whose psABIs specify REL as the canonical format: addends can be easily read by a tool. Reviewed By: grimar, mcgrathr Differential Revision: https://reviews.llvm.org/D80496
2020-05-30 05:22:03 +08:00
# REL-NEXT: }
# REL-NEXT: .rel.plt {
[llvm-readobj] - For SHT_REL relocations, don't display an addend. This is https://bugs.llvm.org/show_bug.cgi?id=44257. In LLVM style we always print `0` as addend when dumping SHT_REL relocations. It is confusing, this patch stops printing it as the first comment on the bug page suggests. Differential revision: https://reviews.llvm.org/D93033
2020-12-10 21:12:26 +08:00
# REL-NEXT: R_X86_64_JUMP_SLOT func
[ELF] Add -z rel and -z rela LLD supports both REL and RELA for static relocations, but emits either of REL and RELA for dynamic relocations. The relocation entry format is specified by each psABI. musl ld.so supports both REL and RELA. For such ld.so implementations, REL (.rel.dyn .rel.plt) has size benefits even if the psABI chooses RELA: sizeof(Elf64_Rel)=16 < sizeof(Elf64_Rela)=24. * COPY, GLOB_DAT and J[U]MP_SLOT always have 0 addend. A ld.so implementation does not need to read the implicit addend. REL is strictly better. * A RELATIVE has a non-zero addend. Such relocations can be packed compactly with the RELR relocation entry format, which is out of scope of this patch. * For other dynamic relocation types (e.g. symbolic relocation R_X86_64_64), a ld.so implementation needs to read the implicit addend. REL may have minor performance impact, because reading implicit addends forces random access reads instead of being able to blast out a bunch of writes while chasing the relocation array. This patch adds -z rel and -z rela to change the relocation entry format for dynamic relocations. I have tested that a -z rel produced x86-64 executable works with musl ld.so -z rela may be useful for debugging purposes on processors whose psABIs specify REL as the canonical format: addends can be easily read by a tool. Reviewed By: grimar, mcgrathr Differential Revision: https://reviews.llvm.org/D80496
2020-05-30 05:22:03 +08:00
# REL-NEXT: }
# REL: Hex dump of section '.data':
# REL-NEXT: 0x00003408 08340000 00000000 2a000000 00000000
.globl _start
_start:
call func@PLT
movq func@GOTPCREL(%rip), %rax
.data
.quad .data
.quad _start+42