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.s

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

30 lines
847 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
# RUN: ld.lld %t -o %t2
[PPC][PPC64] Improve some llvm-objdump -d -D tests Various improvement: Some offsets in disassembly are incorrect after several layout adjustment. Fix them. llvm-objdump -D should not be used. -D dumps unrelated non-text sections. Replace them with llvm-objdump -d, llvm-readelf -x, etc Many llvm-objdump -d tests use {{.*}} . Add the option --no-show-raw-insn to avoid check hex bytes. ppc64-long-branch.s does not need a shared object. Delete it. Make ppc64-ifunc.s check 2 ifuncs. Reviewers: ruiu, espindola Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60998 llvm-svn: 358975
2019-04-23 19:47:28 +08:00
# RUN: llvm-objdump -d --no-show-raw-insn %t2 | 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
Revert "r250372 - [ELF2/PPC64] Remove now-dead weak/undef check" Unfortunately, the check was not as dead as I had thought, and adjusting the starting VA again exposed the problem. We end up trying to relocate the bl (using a 24-bit relative offset) to a symbol address of zero, and in general, that does not fit. Thus, reverting for now, and adding a test case. llvm-svn: 250423
2015-10-16 00:12:35 +08:00
# RUN: llvm-mc -filetype=obj -triple=powerpc64-unknown-linux %s -o %t
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 %t -o %t2
[PPC][PPC64] Improve some llvm-objdump -d -D tests Various improvement: Some offsets in disassembly are incorrect after several layout adjustment. Fix them. llvm-objdump -D should not be used. -D dumps unrelated non-text sections. Replace them with llvm-objdump -d, llvm-readelf -x, etc Many llvm-objdump -d tests use {{.*}} . Add the option --no-show-raw-insn to avoid check hex bytes. ppc64-long-branch.s does not need a shared object. Delete it. Make ppc64-ifunc.s check 2 ifuncs. Reviewers: ruiu, espindola Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60998 llvm-svn: 358975
2019-04-23 19:47:28 +08:00
# RUN: llvm-objdump -d --no-show-raw-insn %t2 | FileCheck %s
Revert "r250372 - [ELF2/PPC64] Remove now-dead weak/undef check" Unfortunately, the check was not as dead as I had thought, and adjusting the starting VA again exposed the problem. We end up trying to relocate the bl (using a 24-bit relative offset) to a symbol address of zero, and in general, that does not fit. Thus, reverting for now, and adding a test case. llvm-svn: 250423
2015-10-16 00:12:35 +08:00
# CHECK: Disassembly of section .text:
[llvm-objdump] Print newlines before and after "Disassembly of section ...:" This improves readability and the behavior is consistent with GNU objdump. The new test test/tools/llvm-objdump/X86/disassemble-section-name.s checks we print newlines before and after "Disassembly of section ...:" Differential Revision: https://reviews.llvm.org/D61127 llvm-svn: 359668
2019-05-01 18:40:48 +08:00
# CHECK-EMPTY:
Revert "r250372 - [ELF2/PPC64] Remove now-dead weak/undef check" Unfortunately, the check was not as dead as I had thought, and adjusting the starting VA again exposed the problem. We end up trying to relocate the bl (using a 24-bit relative offset) to a symbol address of zero, and in general, that does not fit. Thus, reverting for now, and adding a test case. llvm-svn: 250423
2015-10-16 00:12:35 +08:00
[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
.text
Revert "r250372 - [ELF2/PPC64] Remove now-dead weak/undef check" Unfortunately, the check was not as dead as I had thought, and adjusting the starting VA again exposed the problem. We end up trying to relocate the bl (using a 24-bit relative offset) to a symbol address of zero, and in general, that does not fit. Thus, reverting for now, and adding a test case. llvm-svn: 250423
2015-10-16 00:12:35 +08:00
.global _start
_start:
bl weakfunc
nop
blr
.weak weakfunc
# It does not really matter how we fixup the bl, if at all, because it needs to
[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
# be unreachable. But, we should link successfully. We should not, however,
# generate a .plt entry (this would be wasted space). For now, we do nothing
# (leaving the zero relative offset present in the input).
[PPCInstPrinter] Change printBranchOperand(calltarget) to print the target address in hexadecimal form ``` // llvm-objdump -d output (before) 0: bl .-4 4: bl .+0 8: bl .+4 // llvm-objdump -d output (after) ; GNU objdump -d 0: bl 0xfffffffc / bl 0xfffffffffffffffc 4: bl 0x4 8: bl 0xc ``` Many Operand's are not annotated as OPERAND_PCREL. They are not affected (e.g. `b .+67108860`). I plan to fix them in future patches. Modified test/tools/llvm-objdump/ELF/PowerPC/branch-offset.s to test address space wraparound for powerpc32 and powerpc64. Reviewed By: sfertile, jhenderson Differential Revision: https://reviews.llvm.org/D76591
2020-03-23 14:03:09 +08:00
# CHECK: 10010158: bl 0x10010158
[ELF][PPC] Allow PT_LOAD to have overlapping p_offset ranges This change affects the non-linker script case (precisely, when the `SECTIONS` command is not used). It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of a powerpc64 binary can be decreased by at most 192kb. The technique can be ported to other targets. Let me demonstrate the idea with a maxPageSize=65536 example: When assigning the address to the first output section of a new PT_LOAD, if the end p_vaddr of the previous PT_LOAD is 0x10020, we advance to the next multiple of maxPageSize: 0x20000. The new PT_LOAD will thus have p_vaddr=0x20000. Because p_offset and p_vaddr are congruent modulo maxPageSize, p_offset will be 0x20000, leaving a p_offset gap [0x10020, 0x20000) in the output. Alternatively, if we advance to 0x20020, the new PT_LOAD will have p_vaddr=0x20020. We can pick either 0x10020 or 0x20020 for p_offset! Obviously 0x10020 is the choice because it leaves no gap. At runtime, p_vaddr will be rounded down by pagesize (65536 if pagesize=maxPageSize). This PT_LOAD will load additional initial contents from p_offset ranges [0x10000,0x10020), which will also be loaded by the previous PT_LOAD. This is fine if -z noseparate-code is in effect or if we are not transiting between executable and non-executable segments. ld.bfd -z noseparate-code leverages this technique to keep output small. This patch implements the technique in lld, which is mostly effective on targets with large defaultMaxPageSize (AArch64/MIPS/PPC: 65536). The 3 removed alignments can save almost 3*65536 bytes. Two places that rely on p_vaddr%pagesize = 0 have to be updated. 1) We used to round p_memsz(PT_GNU_RELRO) up to commonPageSize (defaults to 4096 on all targets). Now p_vaddr%commonPageSize may be non-zero. The updated formula takes account of that factor. 2) Our TP offsets formulae are only correct if p_vaddr%p_align = 0. Fix them. See the updated comments in InputSection.cpp for details. On targets that we enable the technique (only PPC64 now), we can potentially make `p_vaddr(PT_TLS)%p_align(PT_TLS) != 0` if `sh_addralign(.tdata) < sh_addralign(.tbss)` This exposes many problems in ld.so implementations, especially the offsets of dynamic TLS blocks. Known issues: FreeBSD 13.0-CURRENT rtld-elf (i386/amd64/powerpc/arm64) glibc (HEAD) i386 and x86_64 https://sourceware.org/bugzilla/show_bug.cgi?id=24606 musl<=1.1.22 on TLS Variant I architectures (aarch64/powerpc64/...) So, force p_vaddr%p_align = 0 by rounding dot up to p_align(PT_TLS). The technique will be enabled (with updated tests) for other targets in subsequent patches. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64906 llvm-svn: 369343
2019-08-20 16:34:25 +08:00
# CHECK: 1001015c: nop
# CHECK: 10010160: blr