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/undef-with-plt-addr.s

49 lines
1.3 KiB
ArmAsm
Raw Normal View History

Use the plt entry as the address of some symbols. This is the function equivalent of a copy relocation. Since functions are expected to change sizes, we cannot use copy relocations. In situations where one would be needed, what is done instead is: * Create a plt entry * Output an undefined symbol whose addr is the plt entry. The dynamic linker makes sure any shared library uses the plt entry as the function address. llvm-svn: 260224
2016-02-09 23:11:01 +08:00
// REQUIRES: x86
// RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
// RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %p/Inputs/undef-with-plt-addr.s -o %t2.o
// RUN: ld.lld %t2.o -o %t2.so -shared
// RUN: ld.lld %t.o %t2.so -o %t3
Don't create dynamic relocations to ro segments. These would just crash at runtime. If we ever decide to support rw text segments this should make it easier to implement as there is now a single point where we notice the problem. I have tested this with a freebsd buildworld. It found a non pic assembly file being linked into a .so,. With that fixed, buildworld finished. llvm-svn: 268149
2016-04-30 09:15:17 +08:00
// RUN: llvm-readobj -t -s -r %t3 | FileCheck %s
Use the plt entry as the address of some symbols. This is the function equivalent of a copy relocation. Since functions are expected to change sizes, we cannot use copy relocations. In situations where one would be needed, what is done instead is: * Create a plt entry * Output an undefined symbol whose addr is the plt entry. The dynamic linker makes sure any shared library uses the plt entry as the function address. llvm-svn: 260224
2016-02-09 23:11:01 +08:00
Add a test showing that nocopyreloc is only about copy relocs. For functions the linker uses a related hack: creating a plt in the main executable that preempts the function. Like bfd and gold, we don't disable it with nocopyreloc. llvm-svn: 295976
2017-02-23 22:41:24 +08:00
// Test that -z nocopyreloc doesn't prevent the plt hack.
// RUN: ld.lld %t.o %t2.so -o %t3 -z nocopyreloc
Use the plt entry as the address of some symbols. This is the function equivalent of a copy relocation. Since functions are expected to change sizes, we cannot use copy relocations. In situations where one would be needed, what is done instead is: * Create a plt entry * Output an undefined symbol whose addr is the plt entry. The dynamic linker makes sure any shared library uses the plt entry as the function address. llvm-svn: 260224
2016-02-09 23:11:01 +08:00
.globl _start
_start:
movabsq $set_data, %rax
Don't create dynamic relocations to ro segments. These would just crash at runtime. If we ever decide to support rw text segments this should make it easier to implement as there is now a single point where we notice the problem. I have tested this with a freebsd buildworld. It found a non pic assembly file being linked into a .so,. With that fixed, buildworld finished. llvm-svn: 268149
2016-04-30 09:15:17 +08:00
.data
.quad foo
// Test that set_data has an address in the .plt, but foo is not
Use the plt entry as the address of some symbols. This is the function equivalent of a copy relocation. Since functions are expected to change sizes, we cannot use copy relocations. In situations where one would be needed, what is done instead is: * Create a plt entry * Output an undefined symbol whose addr is the plt entry. The dynamic linker makes sure any shared library uses the plt entry as the function address. llvm-svn: 260224
2016-02-09 23:11:01 +08:00
// CHECK: Name: .plt
// CHECK-NEXT: Type: SHT_PROGBITS
// CHECK-NEXT: Flags [
// CHECK-NEXT: SHF_ALLOC
// CHECK-NEXT: SHF_EXECINSTR
// CHECK-NEXT: ]
lld: Default image base address to 0x200000 on x86-64 Align to the large page size (known as a superpage or huge page). FreeBSD automatically promotes large, superpage-aligned allocations. Differential Revision: https://reviews.llvm.org/D27042 llvm-svn: 287782
2016-11-24 01:44:02 +08:00
// CHECK-NEXT: Address: 0x201010
Use the plt entry as the address of some symbols. This is the function equivalent of a copy relocation. Since functions are expected to change sizes, we cannot use copy relocations. In situations where one would be needed, what is done instead is: * Create a plt entry * Output an undefined symbol whose addr is the plt entry. The dynamic linker makes sure any shared library uses the plt entry as the function address. llvm-svn: 260224
2016-02-09 23:11:01 +08:00
Don't create dynamic relocations to ro segments. These would just crash at runtime. If we ever decide to support rw text segments this should make it easier to implement as there is now a single point where we notice the problem. I have tested this with a freebsd buildworld. It found a non pic assembly file being linked into a .so,. With that fixed, buildworld finished. llvm-svn: 268149
2016-04-30 09:15:17 +08:00
// CHECK: Section ({{.*}}) .rela.dyn {
ELF: Place relro sections after non-relro sections in r/w segment. This is in preparation for my next change, which will introduce a relro nobits section. That requires that relro sections appear at the end of the progbits part of the r/w segment so that the relro nobits section can appear contiguously. Because of the amount of churn required in the test suite, I'm making this change separately. llvm-svn: 291523
2017-01-10 09:21:30 +08:00
// CHECK-NEXT: 0x202000 R_X86_64_64 foo 0x0
Don't create dynamic relocations to ro segments. These would just crash at runtime. If we ever decide to support rw text segments this should make it easier to implement as there is now a single point where we notice the problem. I have tested this with a freebsd buildworld. It found a non pic assembly file being linked into a .so,. With that fixed, buildworld finished. llvm-svn: 268149
2016-04-30 09:15:17 +08:00
// CHECK-NEXT: }
// CHECK-NEXT: Section ({{.*}}) .rela.plt {
ELF: Place relro sections after non-relro sections in r/w segment. This is in preparation for my next change, which will introduce a relro nobits section. That requires that relro sections appear at the end of the progbits part of the r/w segment so that the relro nobits section can appear contiguously. Because of the amount of churn required in the test suite, I'm making this change separately. llvm-svn: 291523
2017-01-10 09:21:30 +08:00
// CHECK-NEXT: 0x202020 R_X86_64_JUMP_SLOT set_data 0x0
Don't create dynamic relocations to ro segments. These would just crash at runtime. If we ever decide to support rw text segments this should make it easier to implement as there is now a single point where we notice the problem. I have tested this with a freebsd buildworld. It found a non pic assembly file being linked into a .so,. With that fixed, buildworld finished. llvm-svn: 268149
2016-04-30 09:15:17 +08:00
// CHECK-NEXT: }
// CHECK: Name: foo
// CHECK-NEXT: Value: 0x0
// CHECK-NEXT: Size: 0
// CHECK-NEXT: Binding: Global
// CHECK-NEXT: Type: Function
// CHECK-NEXT: Other: 0
// CHECK-NEXT: Section: Undefined
Use the plt entry as the address of some symbols. This is the function equivalent of a copy relocation. Since functions are expected to change sizes, we cannot use copy relocations. In situations where one would be needed, what is done instead is: * Create a plt entry * Output an undefined symbol whose addr is the plt entry. The dynamic linker makes sure any shared library uses the plt entry as the function address. llvm-svn: 260224
2016-02-09 23:11:01 +08:00
// CHECK: Name: set_data
lld: Default image base address to 0x200000 on x86-64 Align to the large page size (known as a superpage or huge page). FreeBSD automatically promotes large, superpage-aligned allocations. Differential Revision: https://reviews.llvm.org/D27042 llvm-svn: 287782
2016-11-24 01:44:02 +08:00
// CHECK-NEXT: Value: 0x201020
Don't create dynamic relocations to ro segments. These would just crash at runtime. If we ever decide to support rw text segments this should make it easier to implement as there is now a single point where we notice the problem. I have tested this with a freebsd buildworld. It found a non pic assembly file being linked into a .so,. With that fixed, buildworld finished. llvm-svn: 268149
2016-04-30 09:15:17 +08:00
// CHECK-NEXT: Size: 0
// CHECK-NEXT: Binding: Global
// CHECK-NEXT: Type: Function
// CHECK-NEXT: Other: 0
// CHECK-NEXT: Section: Undefined