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/i386-zrel-zrela.s

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

64 lines
1.8 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 i386 psABI uses Elf64_Rela relocation entries. We produce
## Elf32_Rel dynamic relocations by default, but can use Elf32_Rela with -z rela.
# RUN: llvm-mc -filetype=obj -triple=i386 %s -o %t.o
# RUN: ld.lld -shared %t.o -o %t.so
# RUN: llvm-readobj -d -r -x .data %t.so | FileCheck --check-prefix=REL %s
# RUN: ld.lld -shared -z rel %t.o -o %t1.so
# RUN: llvm-readobj -d -r -x .data %t1.so | FileCheck --check-prefix=REL %s
# REL: REL {{.*}}
# REL-NEXT: RELSZ 32 (bytes)
# REL-NEXT: RELENT 8 (bytes)
# REL-NEXT: RELCOUNT 1
# REL-NEXT: JMPREL {{.*}}
# REL-NEXT: PLTRELSZ 8 (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_386_RELATIVE -
# REL-NEXT: R_386_GLOB_DAT func
# REL-NEXT: R_386_TLS_TPOFF tls
# REL-NEXT: R_386_32 _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_386_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':
[ELF] Reject local-exec TLS relocations for -shared For x86-64, D33100 added a diagnostic for local-exec TLS relocations referencing a preemptible symbol. This patch generalizes it to non-preemptible symbols (see `-Bsymbolic` in `tls.s`) on all targets. Local-exec TLS relocations resolve to offsets relative to a fixed point within the static TLS block, which are only meaningful for the executable. With this change, `clang -fpic -shared -fuse-ld=bfd a.c` on the following example will be flagged for AArch64/ARM/i386/x86-64/RISC-V ``` static __attribute__((tls_model("local-exec"))) __thread long TlsVar = 42; long bump() { return ++TlsVar; } ``` Note, in GNU ld, at least arm, riscv and x86's ports have the similar diagnostics, but aarch64 and ppc64 do not error. Differential Revision: https://reviews.llvm.org/D93331
2020-12-22 00:47:04 +08:00
# REL-NEXT: 0x000042d0 d0420000 2a000000
[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
# RUN: ld.lld -shared -z rel -z rela %t.o -o %t2.so
# RUN: llvm-readobj -d -r %t2.so | FileCheck --check-prefix=RELA %s
# RELA: RELA {{.*}}
# RELA-NEXT: RELASZ 48 (bytes)
# RELA-NEXT: RELAENT 12 (bytes)
# RELA-NEXT: RELACOUNT 1
# RELA-NEXT: JMPREL {{.*}}
# RELA-NEXT: PLTRELSZ 12 (bytes)
# RELA-NEXT: PLTGOT {{.*}}
# RELA-NEXT: PLTREL RELA
# RELA: .rela.dyn {
[ELF] Reject local-exec TLS relocations for -shared For x86-64, D33100 added a diagnostic for local-exec TLS relocations referencing a preemptible symbol. This patch generalizes it to non-preemptible symbols (see `-Bsymbolic` in `tls.s`) on all targets. Local-exec TLS relocations resolve to offsets relative to a fixed point within the static TLS block, which are only meaningful for the executable. With this change, `clang -fpic -shared -fuse-ld=bfd a.c` on the following example will be flagged for AArch64/ARM/i386/x86-64/RISC-V ``` static __attribute__((tls_model("local-exec"))) __thread long TlsVar = 42; long bump() { return ++TlsVar; } ``` Note, in GNU ld, at least arm, riscv and x86's ports have the similar diagnostics, but aarch64 and ppc64 do not error. Differential Revision: https://reviews.llvm.org/D93331
2020-12-22 00:47:04 +08:00
# RELA-NEXT: R_386_RELATIVE - 0x42F0
[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
# RELA-NEXT: R_386_GLOB_DAT func 0x0
[ELF] Reject local-exec TLS relocations for -shared For x86-64, D33100 added a diagnostic for local-exec TLS relocations referencing a preemptible symbol. This patch generalizes it to non-preemptible symbols (see `-Bsymbolic` in `tls.s`) on all targets. Local-exec TLS relocations resolve to offsets relative to a fixed point within the static TLS block, which are only meaningful for the executable. With this change, `clang -fpic -shared -fuse-ld=bfd a.c` on the following example will be flagged for AArch64/ARM/i386/x86-64/RISC-V ``` static __attribute__((tls_model("local-exec"))) __thread long TlsVar = 42; long bump() { return ++TlsVar; } ``` Note, in GNU ld, at least arm, riscv and x86's ports have the similar diagnostics, but aarch64 and ppc64 do not error. Differential Revision: https://reviews.llvm.org/D93331
2020-12-22 00:47:04 +08:00
# RELA-NEXT: R_386_TLS_TPOFF tls 0x0
[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
# RELA-NEXT: R_386_32 _start 0x2A
# RELA-NEXT: }
# RELA-NEXT: .rela.plt {
# RELA-NEXT: R_386_JUMP_SLOT func 0x0
# RELA-NEXT: }
.globl _start
_start:
call func@PLT
movl func@GOT(%eax), %eax
.section .text1,"awx"
[ELF] Reject local-exec TLS relocations for -shared For x86-64, D33100 added a diagnostic for local-exec TLS relocations referencing a preemptible symbol. This patch generalizes it to non-preemptible symbols (see `-Bsymbolic` in `tls.s`) on all targets. Local-exec TLS relocations resolve to offsets relative to a fixed point within the static TLS block, which are only meaningful for the executable. With this change, `clang -fpic -shared -fuse-ld=bfd a.c` on the following example will be flagged for AArch64/ARM/i386/x86-64/RISC-V ``` static __attribute__((tls_model("local-exec"))) __thread long TlsVar = 42; long bump() { return ++TlsVar; } ``` Note, in GNU ld, at least arm, riscv and x86's ports have the similar diagnostics, but aarch64 and ppc64 do not error. Differential Revision: https://reviews.llvm.org/D93331
2020-12-22 00:47:04 +08:00
movl tls@GOTNTPOFF(%eax), %eax
[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
.data
.long .data
.long _start+42