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/ppc64-weak-undef-call-shared.s

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

22 lines
519 B
ArmAsm
Raw Normal View History

[PPC64] Remove support for ELF V1 ABI in LLD The current support for V1 ABI in LLD is incomplete. This patch removes V1 ABI support and changes the default behavior to V2 ABI, issuing an error when using the V1 ABI. It also updates the testcases to V2 and removes any V1 specific tests. Differential Revision: https://reviews.llvm.org/D46316 llvm-svn: 331529
2018-05-04 23:09:49 +08:00
# REQUIRES: ppc
# RUN: llvm-mc -filetype=obj -triple=powerpc64le-unknown-linux %s -o %t.o
# RUN: ld.lld -shared %t.o -o %t.so
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj --symbols -r --dyn-syms %t.so | FileCheck %s
[PPC64] Remove support for ELF V1 ABI in LLD The current support for V1 ABI in LLD is incomplete. This patch removes V1 ABI support and changes the default behavior to V2 ABI, issuing an error when using the V1 ABI. It also updates the testcases to V2 and removes any V1 specific tests. Differential Revision: https://reviews.llvm.org/D46316 llvm-svn: 331529
2018-05-04 23:09:49 +08:00
[ELF2] Don't create RelativeReloc for weak undef symbols When we have a R_PPC64_ADDR64 for a weak undef symbol, which thus resolves to 0, and we're creating a shared library, we need to make sure that it stays 0 (because code that conditionally calls the weak function tests for this). Unfortunately, we were creating a R_PPC64_RELATIVE for these relocation targets, making the address of the undefined weak symbol equal to the base address of the shared library (which is non-zero). In general, we should not be creating RelativeReloc relocs for undef weak symbols. llvm-svn: 250558
2015-10-17 06:11:05 +08:00
# RUN: llvm-mc -filetype=obj -triple=powerpc64-unknown-linux %s -o %t.o
Rename ld.lld2 to ld.lld since it is the default. llvm-svn: 253437
2015-11-18 14:11:01 +08:00
# RUN: ld.lld -shared %t.o -o %t.so
[test] Change llvm-readobj -long-option to --long-option or well-known short options. NFC Also change some options that have different semantics (cause confusion) in llvm-readelf mode: -s => -S -t => --symbols -sd => --section-data llvm-svn: 359651
2019-05-01 13:49:01 +08:00
# RUN: llvm-readobj --symbols -r --dyn-syms %t.so | FileCheck %s
[ELF2] Don't create RelativeReloc for weak undef symbols When we have a R_PPC64_ADDR64 for a weak undef symbol, which thus resolves to 0, and we're creating a shared library, we need to make sure that it stays 0 (because code that conditionally calls the weak function tests for this). Unfortunately, we were creating a R_PPC64_RELATIVE for these relocation targets, making the address of the undefined weak symbol equal to the base address of the shared library (which is non-zero). In general, we should not be creating RelativeReloc relocs for undef weak symbols. llvm-svn: 250558
2015-10-17 06:11:05 +08:00
.section ".toc","aw"
.quad weakfunc
// CHECK-NOT: R_PPC64_RELATIVE
[ELF2/PPC64] Don't create .plt entries for weak undef symbols Instead of specifically creating .plt entries for weak undef symbols, mirror the logic in r250584, and use canBePreempted to determine is a REL24 relocation needs a .plt entry. This might cause relocateOne to be called for a weak undef symbol, with a REL24 relocation, but ignore this as a special case (this will cause SA == 0, which won't happen under any other circumstance). llvm-svn: 250597
2015-10-17 08:48:20 +08:00
.text
.Lfoo:
bl weakfunc
[PPC64] Fix toc restore nops offset for V2 ABI The PPC64 V2 ABI restores the toc base by loading from an offset of 24 from r1. This patch fixes the offset and updates the testcases from V1 to V2. It also issues an error when a nop is missing after a call to an external function. Differential Revision: https://reviews.llvm.org/D45892 llvm-svn: 330600
2018-04-23 23:01:24 +08:00
nop
[ELF2/PPC64] Don't create .plt entries for weak undef symbols Instead of specifically creating .plt entries for weak undef symbols, mirror the logic in r250584, and use canBePreempted to determine is a REL24 relocation needs a .plt entry. This might cause relocateOne to be called for a weak undef symbol, with a REL24 relocation, but ignore this as a special case (this will cause SA == 0, which won't happen under any other circumstance). llvm-svn: 250597
2015-10-17 08:48:20 +08:00
// CHECK-NOT: R_PPC64_REL24
[ELF2] Don't create RelativeReloc for weak undef symbols When we have a R_PPC64_ADDR64 for a weak undef symbol, which thus resolves to 0, and we're creating a shared library, we need to make sure that it stays 0 (because code that conditionally calls the weak function tests for this). Unfortunately, we were creating a R_PPC64_RELATIVE for these relocation targets, making the address of the undefined weak symbol equal to the base address of the shared library (which is non-zero). In general, we should not be creating RelativeReloc relocs for undef weak symbols. llvm-svn: 250558
2015-10-17 06:11:05 +08:00
.weak weakfunc