summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Arch/PPC64.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [ELF][PowerPC] Support R_PPC_COPY and R_PPC64_COPYFangrui Song2020-01-241-0/+1
| | | | | | | | Reviewed By: Bdragon28, jhenderson, grimar, sfertile Differential Revision: https://reviews.llvm.org/D73255 (cherry picked from commit f1dab29908d25a4044abff6ffc120c48b20f034d)
* [ELF][PPC64] Implement IPLT code sequence for non-preemptible IFUNCFangrui Song2019-12-291-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Non-preemptible IFUNC are placed in in.iplt (.glink on EM_PPC64). If there is a non-GOT non-PLT relocation, for pointer equality, we change the type of the symbol from STT_IFUNC and STT_FUNC and bind it to the .glink entry. On EM_386, EM_X86_64, EM_ARM, and EM_AARCH64, the PLT code sequence loads the address from its associated .got.plt slot. An IPLT also has an associated .got.plt slot and can use the same code sequence. On EM_PPC64, the PLT code sequence is actually a bl instruction in .glink . It jumps to `__glink_PLTresolve` (the PLT header). and `__glink_PLTresolve` computes the .plt slot (relocated by R_PPC64_JUMP_SLOT). An IPLT does not have an associated R_PPC64_JUMP_SLOT, so we cannot use `bl` in .iplt . Instead, create a call stub which has a similar code sequence as PPC64PltCallStub. We don't save the TOC pointer, so such scenarios will not work: a function pointer to a non-preemptible ifunc, which resolves to a function defined in another DSO. This is the restriction described by https://sourceware.org/glibc/wiki/GNU_IFUNC (though on many architectures it works in practice): Requirement (a): Resolver must be defined in the same translation unit as the implementations. If an ifunc is taken address but not called, technically we don't need an entry for it, but we currently do that. This patch makes // clang -fuse-ld=lld -fno-pie -no-pie a.c // clang -fuse-ld=lld -fPIE -pie a.c #include <stdio.h> static void impl(void) { puts("meow"); } void thefunc(void) __attribute__((ifunc("resolver"))); void *resolver(void) { return &impl; } int main(void) { thefunc(); void (*theptr)(void) = &thefunc; theptr(); } work on Linux glibc and FreeBSD. Calling a function pointer pointing to a Non-preemptible IFUNC never worked before. Differential Revision: https://reviews.llvm.org/D71509
* [ELF] writePlt, writeIplt: replace parameters gotPltEntryAddr and index with ↵Fangrui Song2019-12-181-5/+5
| | | | | | | | | | `const Symbol &`. NFC PPC::writeIplt (IPLT code sequence, D71621) needs to access `Symbol`. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D71631
* [ELF] Add IpltSectionFangrui Song2019-12-171-1/+2
| | | | | | | | | | | | | | | | | | | PltSection is used by both PLT and IPLT. The PLT section may have a header while the IPLT section does not. Split off IpltSection from PltSection to be clearer. Unlike other targets, PPC64 cannot use the same code sequence for PLT and IPLT. This helps make a future PPC64 patch (D71509) more isolated. On EM_386 and EM_X86_64, when PLT is empty while IPLT is not, currently we are inconsistent whether the PLT header is conceptually attached to in.plt or in.iplt . Consistently attach the header to in.plt can make the -z retpolineplt logic simpler. It also makes `jmp` point to an aesthetically better place for non-retpolineplt cases. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D71519
* [ELF] Delete relOff from TargetInfo::writePLTFangrui Song2019-12-161-3/+2
| | | | | | | | | | | | | | This change only affects EM_386. relOff can be computed from `index` easily, so it is unnecessarily passed as a parameter. Both in.plt and in.iplt entries are written by writePLT. For in.iplt, the instruction `push reloc_offset` will change because `index` is now different. Fortunately, this does not matter because `push; jmp` is only used by PLT. IPLT does not need the code sequence. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D71518
* [ELF][PPC64] Support long branch thunks with addendsFangrui Song2019-12-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PPC64 part of PR40438 // clang -target ppc64le -c a.cc // .text.unlikely may be placed in a separate output section (via -z keep-text-section-prefix) // The distance between bar in .text.unlikely and foo in .text may be larger than 32MiB. static void foo() {} __attribute__((section(".text.unlikely"))) static int bar() { foo(); return 0; } __attribute__((used)) static int dummy = bar(); This patch makes such thunks with addends work for PPC64. AArch64: .text -> `__AArch64ADRPThunk_ (adrp x16, ...; add x16, x16, ...; br x16)` -> target PPC64: .text -> `__long_branch_ (addis 12, 2, ...; ld 12, ...(12); mtctr 12; bctr)` -> target AArch64 can leverage ADRP to jump to the target directly, but PPC64 needs to load an address from .branch_lt . Before Power ISA v3.0, the PC-relative ADDPCIS was not available. .branch_lt was invented to work around the limitation. Symbol::ppc64BranchltIndex is replaced by PPC64LongBranchTargetSection::entry_index which take addends into consideration. The tests are rewritten: ppc64-long-branch.s tests -no-pie and ppc64-long-branch-pi.s tests -pie and -shared. Reviewed By: sfertile Differential Revision: https://reviews.llvm.org/D70937
* [ELF][AArch64] Support R_AARCH64_{CALL26,JUMP26} range extension thunks with ↵Fangrui Song2019-12-021-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | addends Fixes AArch64 part of PR40438 The current range extension thunk framework does not handle a relocation relative to a STT_SECTION symbol with a non-zero addend, which may be used by jumps/calls to local functions on some RELA targets (AArch64, powerpc ELFv1, powerpc64 ELFv2, etc). See PR40438 and the following code for examples: // clang -target $target a.cc // .text.cold may be placed in a separate output section. // The distance between bar in .text.cold and foo in .text may be larger than 128MiB. static void foo() {} __attribute__((section(".text.cold"))) static int bar() { foo(); return 0; } __attribute__((used)) static int dummy = bar(); This patch makes such thunks with addends work for AArch64. The target independent part can be reused by PPC in the future. On REL targets (ARM, MIPS), jumps/calls are not represented as STT_SECTION + non-zero addend (see MCELFObjectTargetWriter::needsRelocateWithSymbol), so they don't need this feature, but we need to make sure this patch does not affect them. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D70637
* Fix a few typos in lld/ELF to cycle botsNico Weber2019-10-281-3/+3
|
* [ELF] Wrap things in `namespace lld { namespace elf {`, NFCFangrui Song2019-10-071-9/+13
| | | | | | | | | | | This makes it clear `ELF/**/*.cpp` files define things in the `lld::elf` namespace and simplifies `elf::foo` to `foo`. Reviewed By: atanasyan, grimar, ruiu Differential Revision: https://reviews.llvm.org/D68323 llvm-svn: 373885
* [ELF][PPC] Fix getRelExpr for R_PPC64_REL16_HIFangrui Song2019-08-171-0/+1
| | | | | | | | | | | | Fixes https://github.com/ClangBuiltLinux/linux/issues/640 R_PPC64_REL16_HI was incorrectly computed as an R_ABS relocation. rLLD368964 made it a linker failure. Change it to use R_PC to fix the failures. Add ppc64-reloc-rel.s for these R_PPC64_REL* tests. llvm-svn: 369184
* [ELF][PPC] Improve error message for unknown relocationsFangrui Song2019-08-151-2/+19
| | | | | | | | | | | | | | Like rLLD354040. Previously, for unrecognized relocation types, in -no-pie mode: foo.o: unrecognized reloc 256 In -pie/-shared mode: error: can't create dynamic relocation R_PPC_xxx against symbol: yyy in readonly segment llvm-svn: 368964
* [ELF] Don't special case symbolic relocations with 0 addend to ifunc in ↵Fangrui Song2019-08-131-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | writable locations Currently the following 3 relocation types do not trigger the creation of a canonical PLT (which changes STT_GNU_IFUNC to STT_FUNC and redirects all references): 1) GOT-generating (`needsGot`) 2) PLT-generating (`needsPlt`) 3) R_ABS with 0 addend in a writable location. This is used for for ifunc function pointers in writable sections such as .data and .toc. This patch deletes case 3) to simplify the R_*_IRELATIVE generating logic added in D57371. Other advantages: * It is guaranteed no more than 1 R_*_IRELATIVE is created for an ifunc. * PPC64: no need to special case ifunc in toc-indirect to toc-relative relaxation. See D65755 The deleted elf::addIRelativeRelocs demonstrates that one-pass scan through relocations makes several optimizations difficult. This is something we can think about in the future. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D65995 llvm-svn: 368661
* [ELF][PPC] Don't relax ifunc toc-indirect accesses to toc-relativeFangrui Song2019-08-061-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PR42759. ``` // If ifunc is taken address in -fPIC code, it may have a toc entry .section .toc,"aw",@progbits .quad ifunc // ifunc may be defined as STT_GNU_IFUNC in another object file .type ifunc, %gnu_indirect_function ``` If ifunc is non-preemptable (e.g. when linking an executable), the toc entry will be relocated by R_PPC64_IRELATIVE. R_*_IRELATIVE represents the symbolic value of a non-preemptable ifunc (not associated with a canonical PLT) in a writable location. It has an unknown value at link time, so we cannot apply toc-indirect to toc-relative relaxation. Reviewed By: luporl, sfertile Differential Revision: https://reviews.llvm.org/D65755 llvm-svn: 368057
* [ELF][PPC] Refactor some ppc64 testsFangrui Song2019-07-181-0/+1
| | | | | | | | Merge ppc64-dynamic-relocations.s into ppc64-plt-stub.s Add ppc64-tls-ie.s: covers ppc64-initial-exec-tls.s and ppc64-tls-ie-le.s Add ppc64-tls-gd.s: covers ppc64-general-dynamic-tls.s, ppc64-gd-to-ie.s, ppc64-tls-gd-le.s, and ppc64-tls-gd-le-small.s llvm-svn: 366424
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-101-322/+322
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | letter This patch is mechanically generated by clang-llvm-rename tool that I wrote using Clang Refactoring Engine just for creating this patch. You can see the source code of the tool at https://reviews.llvm.org/D64123. There's no manual post-processing; you can generate the same patch by re-running the tool against lld's code base. Here is the main discussion thread to change the LLVM coding style: https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html In the discussion thread, I proposed we use lld as a testbed for variable naming scheme change, and this patch does that. I chose to rename variables so that they are in camelCase, just because that is a minimal change to make variables to start with a lowercase letter. Note to downstream patch maintainers: if you are maintaining a downstream lld repo, just rebasing ahead of this commit would cause massive merge conflicts because this patch essentially changes every line in the lld subdirectory. But there's a remedy. clang-llvm-rename tool is a batch tool, so you can rename variables in your downstream repo with the tool. Given that, here is how to rebase your repo to a commit after the mass renaming: 1. rebase to the commit just before the mass variable renaming, 2. apply the tool to your downstream repo to mass-rename variables locally, and 3. rebase again to the head. Most changes made by the tool should be identical for a downstream repo and for the head, so at the step 3, almost all changes should be merged and disappear. I'd expect that there would be some lines that you need to merge by hand, but that shouldn't be too many. Differential Revision: https://reviews.llvm.org/D64121 llvm-svn: 365595
* [ELF][PPC][X86] Use [-2**(n-1), 2**n) to check overflows for R_PPC_ADDR16, ↵Fangrui Song2019-06-241-3/+9
| | | | | | | | | | | | | | | | | | | | | R_PPC64_ADDR{16,32}, R_X86_64_{8,16} Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of `[-2**(n-1), 2**(n-1))` to check overflows. The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel. The new behavior is compatible with ld.bfd's complain_overflow_bitfield. The upper bound of the error message is not correct. Fix it as well. The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63690 llvm-svn: 364164
* [ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for ↵Fangrui Song2019-06-201-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | absolute relocation types in writable sections Summary: Our rule to create R_*_RELATIVE for absolute relocation types were loose. D63121 made it stricter but it failed to create R_*_RELATIVE for R_ARM_TARGET1 and R_PPC64_TOC. rLLD363236 worked around that by reinstating the original behavior for ARM and PPC64. This patch is an attempt to simplify the logic. Note, in ld.bfd, R_ARM_TARGET2 --target2=abs also creates R_ARM_RELATIVE. This seems a very uncommon scenario (moreover, --target2=got-rel is the default), so I do not implement any logic related to it. Also, delete R_AARCH64_ABS32 from AArch64::getDynRel. We don't have working ILP32 support yet. Allowing it would create an incorrect R_AARCH64_RELATIVE. For MIPS, the (if SymbolRel, then RelativeRel) code is to keep its behavior unchanged. Note, in ppc64-abs64-dyn.s, R_PPC64_TOC gets an incorrect addend because computeAddend() doesn't compute the correct address. We seem to have the wrong behavior for a long time. The important thing seems that a dynamic relocation R_PPC64_TOC should not be created as the dynamic loader will error R_PPC64_TOC is not supported. Reviewers: atanasyan, grimar, peter.smith, ruiu, sfertile, espindola Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63383 llvm-svn: 363928
* Revert "Revert r362867: [ELF][PPC] Simplify {read,write}FromHalf16"Fangrui Song2019-06-121-28/+29
| | | | | | | | | | | | | | | This reverts commit r363060 and restores r362867. r362867 is innocent. The ppc64le-lld-multistage-test bot failure was due to a clang/gcc .toc bug: ld.lld: error: relocation refers to a discarded section: .rodata._ZNK4llvm3MVT13getSizeInBitsEv >>> defined in utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o >>> referenced by CodeGenRegisters.cpp >>> utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o:(.toc+0x0) It will be worked around by D63182. llvm-svn: 363124
* Revert r362867: [ELF][PPC] Simplify {read,write}FromHalf16Rui Ueyama2019-06-111-29/+28
| | | | | | | This reverts commit r362867 since it seems to have broken ppc64le-lld-multistage-test bot. llvm-svn: 363060
* [ELF] Make the rule to create relative relocations in a writable section ↵Fangrui Song2019-06-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | stricter The current rule is loose: `!Sym.IsPreemptible || Expr == R_GOT`. When the symbol is non-preemptable, this allows absolute relocation types with smaller numbers of bits, e.g. R_X86_64_{8,16,32}. They are disallowed by ld.bfd and gold, e.g. ld.bfd: a.o: relocation R_X86_64_8 against `.text' can not be used when making a shared object; recompile with -fPIC This patch: a) Add TargetInfo::SymbolicRel to represent relocation types that resolve to a symbol value (e.g. R_AARCH_ABS64, R_386_32, R_X86_64_64). As a side benefit, we currently (ab)use GotRel (R_*_GLOB_DAT) to resolve GOT slots that are link-time constants. Since we now use Target->SymbolRel to do the job, we can remove R_*_GLOB_DAT from relocateOne() for all targets. R_*_GLOB_DAT cannot be used as static relocation types. b) Change the condition to `!Sym.IsPreemptible && Type != Target->SymbolicRel || Expr == R_GOT`. Some tests are caught by the improved error checking (ld.bfd/gold also issue errors on them). Many misuse .long where .quad should be used instead. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63121 llvm-svn: 363059
* [ELF][PPC] Simplify {read,write}FromHalf16Fangrui Song2019-06-081-28/+29
| | | | | | | | | | | | | | | I've change the variable names used in PPC64.cpp from "Instr" to "Insn" because "Insn" is a more common abbreviation for "instruction". While changing PPC64.cpp relocateOne(), make R_PPC64_ADDR16_LO{_DS} slightly more efficient by saving a read and a write for the TocOptimize case. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63043 llvm-svn: 362867
* [PPC32] Support GD/LD/IE/LE TLS models and their relaxationsFangrui Song2019-06-061-3/+4
| | | | | | | | Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62940 llvm-svn: 362722
* [ELF][PPC64] Rename some PPC64 ELFv2 specific RelExpr from R_PPC_* to R_PPC64_*Fangrui Song2019-06-031-2/+2
| | | | | | | | | | | | | | | | | | The following abstract relocation types (RelExpr) are PPC64 ELFv2 ABI specific, not used by PPC32. So rename them to prevent confusion when the PPC32 port is improved. * R_PPC_CALL R_PPC_CALL_PLT: R_PPC_CALL_PLT represents R_PPC64_REL14 and R_PPC64_REL24. If the function is not preemptable, R_PPC_CALL_PLT can be optimized to R_PPC_CALL: the formula adjusts the symbol VA from the global entry point to the local entry point. * R_PPC_TOC: represents R_PPC64_TOC. We don't have a test. Add one to ppc64-relocs.s Rename it to R_PPC64_TOCBASE because `@tocbase` is the assembly form. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62800 llvm-svn: 362359
* [ELF][PPC64] Don't apply LD->LE relaxation on R_PPC64_GOT_DTPREL16*Fangrui Song2019-06-031-4/+0
| | | | | | | | | | | | | | In ELF v2 ABI, R_PPC64_GOT_DTPREL16* are not relaxed. This family of relocation types are used for variables outside of 2GiB of the TLS block. 2 instructions cannot materialize a DTPREL offset that is not 32-bit. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62737 llvm-svn: 362357
* [ELF] Delete GotEntrySize and GotPltEntrySizeFangrui Song2019-05-311-2/+0
| | | | | | | | | | | | | GotEntrySize and GotPltEntrySize were added in D22288. Later, with the introduction of wordsize() (then Config->Wordsize), they become redundant, because there is no target that sets GotEntrySize or GotPltEntrySize to a number different from Config->Wordsize. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D62727 llvm-svn: 362220
* [LLD][ELF] - Improve diagnostic about unrecognized relocations.George Rimar2019-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | This is a minor improvement inspired by https://bugs.llvm.org/show_bug.cgi?id=38303. A person reported that he observed message complaining about unsupported R_ARM_V4BX: error: can't create dynamic relocation R_ARM_V4BX against local symbol in readonly segment; recompile object files with -fPIC But with -z notext he only saw a relocation number, what is not convenient: error: ../../gfx/cairo/libpixman/src/pixman-arm-neon-asm-bilinear.o:(.text+0x4F0): unrecognized reloc 40 Also, in the error messages we use relocation but not reloc. With this patch we start to print one of the following messages: error: file.o: unrecognized relocation Unknown(999) error: file.o: unrecognized relocation R_X_KNOWN_BY_LLVM_BUT_UNSUPPORTED_BY_LLD_NAME There is no way to write a test for that I believe. Differential revision: https://reviews.llvm.org/D62237 llvm-svn: 361472
* [PPC64] Define getThunkSectionSpacing() based on the range of R_PPC64_REL24Fangrui Song2019-05-101-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Suggested by Sean Fertile and Peter Smith. Thunk section spacing decrease the total number of thunks. I measured a decrease of 1% or less in some large programs, with no perceivable slowdown in link time. Override getThunkSectionSpacing() to enable it. 0x2000000 is the farthest point R_PPC64_REL24 can reach. I tried several numbers and found 0x2000000 works the best. Numbers near 0x2000000 work as well but let's just use the simpler number. As demonstrated by the updated tests, this essentially changes placement of most thunks to the end of the output section. We leverage this property to fix PR40740 reported by Alfredo Dal'Ava Júnior: The output section .init consists of input sections from several object files (crti.o crtbegin.o crtend.o crtn.o). Sections other than the last one do not have a terminator. With this patch, we create the thunk after the last .init input section and thus fix the issue. This is not foolproof but works quite well for such sections (with no terminator) in practice. Reviewed By: ruiu, sfertile Differential Revision: https://reviews.llvm.org/D61720 llvm-svn: 360405
* [PPC64] toc-indirect to toc-relative relaxationFangrui Song2019-05-071-2/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on D54720 by Sean Fertile. When accessing a global symbol which is not defined in the translation unit, compilers will generate instructions that load the address from the toc entry. If the symbol is defined, non-preemptable, and addressable with a 32-bit signed offset from the toc pointer, the address can be computed directly. e.g. addis 3, 2, .LC0@toc@ha # R_PPC64_TOC16_HA ld 3, .LC0@toc@l(3) # R_PPC64_TOC16_LO_DS, load the address from a .toc entry ld/lwa 3, 0(3) # load the value from the address .section .toc,"aw",@progbits .LC0: .tc var[TC],var can be relaxed to addis 3,2,var@toc@ha # this may be relaxed to a nop, addi 3,3,var@toc@l # then this becomes addi 3,2,var@toc ld/lwa 3, 0(3) # load the value from the address We can delete the test ppc64-got-indirect.s as its purpose is covered by newly added ppc64-toc-relax.s and ppc64-toc-relax-constants.s Reviewed By: ruiu, sfertile Differential Revision: https://reviews.llvm.org/D60958 llvm-svn: 360112
* [PPC64] Consider localentry offset when computing branch distanceFangrui Song2019-04-241-1/+4
| | | | | | | | | | | | | | | Summary: We don't take localentry offset into account, and thus may fail to create a long branch when the gap is just a few bytes smaller than 2^25. relocation R_PPC64_REL24 out of range: 33554432 is not in [-33554432, 33554431] relocation R_PPC64_REL24 out of range: 33554436 is not in [-33554432, 33554431] Fix that by adding the offset to the symbol VA. Differential Revision: https://reviews.llvm.org/D61058 llvm-svn: 359094
* [PPC64] Allow R_PPC64_DTPREL* to preemptable local-dynamic symbolsFangrui Song2019-04-231-1/+1
| | | | | | | | Similar to D60945. Differential Revision: https://reviews.llvm.org/D60994 llvm-svn: 358950
* Create an instance of Target after reading all input files. NFC.Rui Ueyama2019-03-281-1/+0
| | | | | | | | This change itself doesn't mean anything, but it helps D59780 because in patch, we don't know whether we need to create a CET-aware PLT or not until we read all input files. llvm-svn: 357194
* [PPC64] Sort .toc sections accessed with small code model relocs.Sean Fertile2019-02-121-7/+3
| | | | | | | | | | | | | A follow up to the intial patch that unblocked linking against libgcc. For lld we don't need to bother tracking which objects have got based small code model relocations. This is due to the fact that the compilers on powerpc64 use the .toc section to generate indirections to symbols (rather then using got relocations) which keeps the got small. This makes overflowing a small code model got relocation very unlikely. Differential Revision: https://reviews.llvm.org/D57245 llvm-svn: 353849
* [PPC64] Set the number of relocations processed for R_PPC64_TLS[GL]D to 2Fangrui Song2019-02-061-0/+15
| | | | | | | | | | | | | | | | | | | | | | Summary: R_PPC64_TLSGD and R_PPC64_TLSLD are used as markers on TLS code sequences. After GD-to-IE or GD-to-LE relaxation, the next relocation R_PPC64_REL24 should be skipped to not create a false dependency on __tls_get_addr. When linking statically, the false dependency may cause an "undefined symbol: __tls_get_addr" error. R_PPC64_GOT_TLSGD16_HA R_PPC64_GOT_TLSGD16_LO R_PPC64_TLSGD R_TLSDESC_CALL R_PPC64_REL24 __tls_get_addr Reviewers: ruiu, sfertile, syzaara, espindola Reviewed By: sfertile Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits, tamur Tags: #llvm Differential Revision: https://reviews.llvm.org/D57673 llvm-svn: 353262
* [PPC64] Reland r351978 'Sort .toc sections accessed with small code model ...'Sean Fertile2019-01-241-0/+9
| | | | | | | | | | | | | | | | | | | | | | | Guessing that the slashes used in the scripts SECTION command was causing the windows related failures in the added test. Original commit message: Small code model global variable access on PPC64 has a very limited range of addressing. The instructions the relocations are used on add an offset in the range [-0x8000, 0x7FFC] to the toc pointer which points to .got +0x8000, giving an addressable range of [.got, .got + 0xFFFC]. While user code can be recompiled with medium and large code models when the binary grows too large for small code model, there are small code model relocations in the crt files and libgcc.a which are typically shipped with the distros, and the ABI dictates that linkers must allow linking of relocatable object files using different code models. To minimze the chance of relocation overflow, any file that contains a small code model relocation should have its .toc section placed closer to the .got then any .toc from a file without small code model relocations. Differential Revision: https://reviews.llvm.org/D56920 llvm-svn: 352071
* Revert "[PPC64] Sort .toc sections accessed with small code model ..."Sean Fertile2019-01-231-9/+0
| | | | | | | This reverts commit ca87c57a3aa4770c9cf0defd4b2feccbc342ee93. Added test fails on several windows buildbots. llvm-svn: 351985
* [PPC64] Sort .toc sections accessed with small code model relocs close to .got.Sean Fertile2019-01-231-0/+9
| | | | | | | | | | | | | | | | | | | Small code model global variable access on PPC64 has a very limited range of addressing. The instructions the relocations are used on add an offset in the range [-0x8000, 0x7FFC] to the toc pointer which points to .got +0x8000, giving an addressable range of [.got, .got + 0xFFFC]. While user code can be recompiled with medium and large code models when the binary grows too large for small code model, there are small code model relocations in the crt files and libgcc.a which are typically shipped with the distros, and the ABI dictates that linkers must allow linking of relocatable object files using different code models. To minimze the chance of relocation overflow, any file that contains a small code model relocation should have its .toc section placed closer to the .got then any .toc from a file without small code model relocations. Differential Revision: https://reviews.llvm.org/D56920 llvm-svn: 351978
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [PPC64] Fix RelType in checkInt and checkAlignment diagnsotics.Sean Fertile2019-01-101-8/+10
| | | | | | | | | | | | In the PPC64 target we map toc-relative relocations, dynamic thread pointer relative relocations, and got relocations into a corresponding ADDR16 relocation type for handling in relocateOne. This patch saves the orignal RelType before mapping to an ADDR16 relocation so that any diagnostic messages will not mistakenly use the mapped type. Differential Revision: https://reviews.llvm.org/D56448 llvm-svn: 350827
* [PPC64] Add toc-optimizations for got based relocations.Sean Fertile2018-12-201-7/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D54907 llvm-svn: 349772
* [PPC64] Support got-based relocations.Sean Fertile2018-12-181-2/+17
| | | | | | Differential Revison: https://reviews.llvm.org/D54859 llvm-svn: 349511
* Remove unreachable code.Rui Ueyama2018-12-041-1/+0
| | | | llvm-svn: 348294
* [PPC][PPC64] PPC_REL14 and PPC64_REL14 relocationsMartell Malone2018-12-041-4/+15
| | | | | | | | | | When linking the linux kernel on ppc64 and ppc ld.lld: error: unrecognized reloc 11 11 is PPC_REL14 and PPC64_REL14 Differential revision: https://reviews.llvm.org/D54868 llvm-svn: 348255
* [ELF] Make TrapInstr and Filler byte arrays. NFC.Simon Atanasyan2018-11-141-2/+1
| | | | | | | | | | | | The uint32_t type does not clearly convey that these fields are interpreted in the target endianness. Converting them to byte arrays should make this more obvious and less error-prone. Patch by James Clarke Differential Revision: http://reviews.llvm.org/D54207 llvm-svn: 346893
* [PPC64] Long branch thunks.Sean Fertile2018-11-141-3/+23
| | | | | | | | | | | | | | | | | | On PowerPC64, when a function call offset is too large to encode in a call instruction the address is stored in a table in the data segment. A thunk is used to load the branch target address from the table relative to the TOC-pointer and indirectly branch to the callee. When linking position-dependent code the addresses are stored directly in the table, for position-independent code the table is allocated and filled in at load time by the dynamic linker. For position-independent code the branch targets could have gone in the .got.plt but using the .branch_lt section for both position dependent and position independent binaries keeps it consitent and helps keep this PPC64 specific logic seperated from the target-independent code handling the .got.plt. Differential Revision: https://reviews.llvm.org/D53408 llvm-svn: 346877
* [PPC64] Use INT32_MIN instead of std::numeric_limits<int32_t>::min()Fangrui Song2018-11-071-2/+1
| | | | | | | | | | | | | | | | | | | | Summary: D53821 fixed the bogus MSVC (at least 2017) C4146 warning (unary minus applied on unsigned type) by using std::numeric_limits<int32_t>::min(). The warning was because -2147483648 is incorrectly treated as unsigned long instead of long long) Let's use INT32_MIN which is arguably more readable. Note, on GCC or clang, -0x80000000 works fine (ILP64: long, LP64: long long). Reviewers: ruiu, jhenderson, sfertile, espindola Reviewed By: sfertile Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54200 llvm-svn: 346356
* [ELF] Refactor per-target TLS layout configuration. NFC.Ryan Prichard2018-10-311-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There are really three different kinds of TLS layouts: * A fixed TLS-to-TP offset. On architectures like PowerPC, MIPS, and RISC-V, the thread pointer points to a fixed offset from the start of the executable's TLS segment. The offset is 0x7000 for PowerPC and MIPS, which allows a signed 16-bit offset to reach 0x1000 of per-thread implementation data and 0xf000 of the application's TLS segment. The size and layout of the TCB isn't relevant to the static linker and might not be known. * A fixed TCB size. This is the format documented as "variant 1" in Ulrich Drepper's TLS spec. The thread pointer points to a 2-word TCB followed by the executable's TLS segment. The first word is always the DTV pointer. Used on ARM. The thread pointer must be aligned to the TLS segment's alignment, possibly creating alignment padding. * Variant 2. This format predates variant 1 and is also documented in Drepper's TLS spec. It allocates the executable's TLS segment before the thread pointer, apparently for backwards-compatibility. It's used on x86 and SPARC. Factor out an lld::elf::getTlsTpOffset() function for use in a follow-up patch for Android. The TcbSize/TlsTpOffset fields are only used in getTlsTpOffset, so replace them with a switch on Config->EMachine. Reviewers: espindola, ruiu, PkmX, jrtc27 Reviewed By: ruiu, PkmX, jrtc27 Subscribers: jyknight, emaste, sdardis, nemanjai, javed.absar, arichardson, kristof.beyls, kbarton, fedor.sergeev, atanasyan, PkmX, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D53905 llvm-svn: 345775
* [ELF][PPC64]Workaround bogus Visual Studio build warningJames Henderson2018-10-301-1/+2
| | | | | | | | | | | | | | | | | Visual Studio has a bug where it converts the integer literal 2147483648 into an unsigned int instead of a long long (i.e. it follows C89 rules). The bug has been reported as: https://developercommunity.visualstudio.com/content/problem/141813/-2147483648-c4146-error.html. Because of this bug, we were getting a signed/unsigned comparison warning in VS2015 from the old code (the subsequent unary negation had no effect on the type). Reviewed by: sfertile Differential Revision: https://reviews.llvm.org/D53821 llvm-svn: 345579
* [ELF][PPC64] Fix a split-stack comment in rLLD344622Fangrui Song2018-10-221-1/+1
| | | | | | The blt- instruction (predicted not to be taken) uses cr7, not the default cr0. llvm-svn: 344948
* [ELF] Format PPC64.cpp, NFCFangrui Song2018-10-221-12/+10
| | | | | | Mainly two mis-indented places. The changes are local so should not interfere with in-review revisions llvm-svn: 344932
* [PPC64] Fix offset checks on rel24 call relocations.Sean Fertile2018-10-181-1/+2
| | | | | | | | | | | | Adjusted the range check on a call instruction from 24 bits signed to 26 bits signed. While the instruction only encodes 24 bits, the target is assumed to be 4 byte aligned, and the value that is encoded in the instruction gets shifted left by 2 to form the offset. Also added a check that the offset is indeed at least 4 byte aligned. Differential Revision: https://reviews.llvm.org/D53401 llvm-svn: 344747
OpenPOWER on IntegriCloud