summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Relocations.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [ELF][RISCV] Add R_RISCV_PC_INDIRECT to isRelExpr()Fangrui Song2019-06-111-1/+2
| | | | | | | | | | | | | So that R_RISCV_PCREL_LO12_[IS] are considered as link-time constants in -pie mode, otherwise there are bogus errors: ld.lld: error: can't create dynamic relocation R_RISCV_PCREL_LO12_I against symbol: .L0 in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63123 llvm-svn: 363064
* [ELF] Make the rule to create relative relocations in a writable section ↵Fangrui Song2019-06-111-14/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Create synthetic sections for loadable partitions.Peter Collingbourne2019-06-071-18/+22
| | | | | | | | | | | | | | | We create several types of synthetic sections for loadable partitions, including: - The dynamic symbol table. This allows code outside of the loadable partitions to find entry points with dlsym. - Creating a dynamic symbol table also requires the creation of several other synthetic sections for the partition, such as the dynamic table and hash table sections. - The partition's ELF header is represented as a synthetic section in the combined output file, and will be used by llvm-objcopy to extract partitions. Differential Revision: https://reviews.llvm.org/D62350 llvm-svn: 362819
* [ELF] Delete R_PPC64_CALL_PLT from isRelExpr()Fangrui Song2019-06-071-2/+1
| | | | | | | | | | | It was added by D46654 but is actually never used. R_PPC64_CALL_PLT (was: R_PPC_CALL_PLT) is a static link-time constant. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62994 llvm-svn: 362788
* Revert "Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION ↵Sean Fertile2019-06-061-3/+11
| | | | | | | | | | symbols if the sections were discarded"" This reverts commit 729111cf1824159bb4dd331cab8a829eab30313f. Reverting the previous commit breaks other LLD buildbots. llvm-svn: 362743
* Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if ↵Sean Fertile2019-06-061-11/+3
| | | | | | | | | | the sections were discarded" This reverts commit 5d3b3188f722456a6470c7effcacf17656406429. Breaks the PowerPC multi-stage buildbot. llvm-svn: 362739
* [PPC32] Improve the 32-bit PowerPC portFangrui Song2019-06-061-16/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many -static/-no-pie/-shared/-pie applications linked against glibc or musl should work with this patch. This also helps FreeBSD PowerPC64 to migrate their lib32 (PR40888). * Fix default image base and max page size. * Support new-style Secure PLT (see below). Old-style BSS PLT is not implemented, so it is not suitable for FreeBSD rtld now because it doesn't support Secure PLT yet. * Support more initial relocation types: R_PPC_ADDR32, R_PPC_REL16*, R_PPC_LOCAL24PC, R_PPC_PLTREL24, and R_PPC_GOT16. The addend of R_PPC_PLTREL24 is special: it decides the call stub PLT type but it should be ignored for the computation of target symbol VA. * Support GNU ifunc * Support .glink used for lazy PLT resolution in glibc * Add a new thunk type: PPC32PltCallStub that is similar to PPC64PltCallStub. It is used by R_PPC_REL24 and R_PPC_PLTREL24. A PLT stub used in -fPIE/-fPIC usually loads an address relative to .got2+0x8000 (-fpie/-fpic code uses _GLOBAL_OFFSET_TABLE_ relative addresses). Two .got2 sections in two object files have different addresses, thus a PLT stub can't be shared by two object files. To handle this incompatibility, change the parameters of Thunk::isCompatibleWith to `const InputSection &, const Relocation &`. PowerPC psABI specified an old-style .plt (BSS PLT) that is both writable and executable. Linkers don't make separate RW- and RWE segments, which causes all initially writable memory (think .data) executable. This is a big security concern so a new PLT scheme (secure PLT) was developed to address the security issue. TLS will be implemented in D62940. glibc older than ~2012 requires .rela.dyn to include .rela.plt, it can not handle the DT_RELA+DT_RELASZ == DT_JMPREL case correctly. A hack (not included in this patch) in LinkerScript.cpp addOrphanSections() to work around the issue: if (Config->EMachine == EM_PPC) { // Older glibc assumes .rela.dyn includes .rela.plt Add(In.RelaDyn); if (In.RelaPlt->isLive() && !In.RelaPlt->Parent) In.RelaDyn->getParent()->addSection(In.RelaPlt); } Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62464 llvm-svn: 362721
* [ELF][PPC64] Rename some PPC64 ELFv2 specific RelExpr from R_PPC_* to R_PPC64_*Fangrui Song2019-06-031-9/+11
| | | | | | | | | | | | | | | | | | 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-6/+1
| | | | | | | | | | | | | | 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: Don't reuse a thunk in a different loadable partition.Peter Collingbourne2019-05-291-4/+15
| | | | | | | | | There's no guarantee that the other partition will be loaded, so it can't be reused. Differential Revision: https://reviews.llvm.org/D62365 llvm-svn: 361926
* [ELF] Implement General Dynamic style TLSDESC for x86-64Fangrui Song2019-05-291-5/+6
| | | | | | | | | | | This handles two initial relocation types R_X86_64_GOTPC32_TLSDESC and R_X86_64_TLSDESC_CALL, as well as the GD->LE and GD->IE relaxations. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62513 llvm-svn: 361911
* Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the ↵Fangrui Song2019-05-281-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | sections were discarded This is implemented by creating Undefined (instead of Defined) for such local STT_SECTION symbols. It allows us to catch errors when there are relocations to such discarded sections (e.g. in PR41693, ld.bfd and gold error but we don't). Updated comdat-discarded-error.s checks we emit friendly error message. For relocatable-eh-frame.s, ld.lld -r a.o a.o will now error "STT_SECTION symbol should be defined" because the section .eh_frame refers to is now an Undefined instead of a Defined. So I have to change `error()` to `warn()` to retain the output. rLLD361144 inadvertently enabled the error for --gdb-index (in LLDDwarfObj<ELFT>::findAux()). Relocations from .debug_info (not in comdat) to .text.* (in comdat) for DW_AT_low_pc are common. If an .text.* was discarded, rLLD361144 would error, which was unexpected. (Note, if we don't error as this patch does, InputSection::relocateNonAlloc() will resolve such relocations). llvm-svn: 361830
* Revert [ELF] Error on relocations to STT_SECTION symbols if the sections ↵Haojian Wu2019-05-281-11/+3
| | | | | | | | | | were discarded This reverts r361792 (git commit cfca5095df0209c60109696d6cc368d49e2c5939), the revision causes link errors internally, will share more details with the author. llvm-svn: 361806
* [ELF] Error on relocations to STT_SECTION symbols if the sections were discardedFangrui Song2019-05-281-3/+11
| | | | | | | | | | | | | | | | | | | This is implemented by creating Undefined (instead of Defined) for such local STT_SECTION symbols. It allows us to catch errors when there are relocations to such discarded sections (e.g. in PR41693, ld.bfd and gold error but we don't). Updated comdat-discarded-error.s checks we emit friendly error message. For relocatable-eh-frame.s, ld.lld -r a.o a.o will now error "STT_SECTION symbol should be defined" because the section .eh_frame refers to is now an Undefined instead of a Defined. So I have to change `error()` to `warn()` to retain the output. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D61583 llvm-svn: 361792
* [ELF] Improve error message for relocations to symbols defined in discarded ↵Fangrui Song2019-05-221-9/+47
| | | | | | | | | | | | | | | | | | | | | sections Rather than report "undefined symbol: ", give more informative message about the object file that defines the discarded section. In particular, PR41133, if the section is a discarded COMDAT, print the section group signature and the object file with the prevailing definition. This is useful to track down some ODR issues. We need to * add `uint32_t DiscardedSecIdx` to Undefined for this feature. * make ComdatGroups public and change its type to DenseMap<CachedHashStringRef, const InputFile *> Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D59649 llvm-svn: 361359
* [ELF] Error on relocations to local undefined symbolsFangrui Song2019-05-211-6/+8
| | | | | | | | | | | | | | | | For a reference to a local symbol, ld.bfd and gold error if the symbol is defined in a discarded section but accept it if the symbol is undefined. This inconsistent behavior seems unnecessary for us (it probably makes sense for them as they differentiate local/global symbols, the error would mean more code). Catch such errors. Symbol index 0 may be used by marker relocations, e.g. R_*_NONE R_ARM_V4BX. Don't error on them. The difference from D61563 (which caused msan failure) is we don't call Sym.computeBinding() on local symbols - VersionId is uninitialized. llvm-svn: 361213
* Revert "[ELF] Error on relocations to local undefined symbols"Dmitri Gribenko2019-05-201-6/+4
| | | | | | | | This reverts commit r361144. It causes a use-of-uninitialized-value in maybeReportUndefined at llvm/tools/lld/ELF/Relocations.cpp:682, as detected by MemorySanitizer when local-undefined-symbol.s test is run. llvm-svn: 361162
* [ELF] Error on relocations to local undefined symbolsFangrui Song2019-05-201-4/+6
| | | | | | | | | | | | | | | | | For a reference to a local symbol, ld.bfd and gold error if the symbol is defined in a discarded section but accept it if the symbol is undefined. This inconsistent behavior seems unnecessary for us (it probably makes sense for them as they differentiate local/global symbols, the error would mean more code). Weaken the condition to getSymbol(Config->IsMips64EL) == 0 to catch such errors. The symbol index can be 0 (e.g. R_*_NONE R_ARM_V4BX) and we shouldn't error on them. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D61563 llvm-svn: 361144
* Make replaceSymbol a member function of Symbol.Rui Ueyama2019-05-201-2/+2
| | | | | | | | | | | | This is a mechanical rewrite of replaceSymbol(A, B) to A->replace(B). I also added a comment to Symbol::replace(). Technically this change is not necessary, but this change makes code a bit more concise. Differential Revision: https://reviews.llvm.org/D62117 llvm-svn: 361123
* Move symbol resolution code out of SymbolTable class.Rui Ueyama2019-05-171-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the last patch of the series of patches to make it possible to resolve symbols without asking SymbolTable to do so. The main point of this patch is the introduction of `elf::resolveSymbol(Symbol *Old, Symbol *New)`. That function resolves or merges given symbols by examining symbol types and call replaceSymbol (which memcpy's New to Old) if necessary. With the new function, we have now separated symbol resolution from symbol lookup. If you already have a Symbol pointer, you can directly resolve the symbol without asking SymbolTable to do that. Now that the nice abstraction become available, I can start working on performance improvement of the linker. As a starter, I'm thinking of making --{start,end}-lib faster. --{start,end}-lib is currently unnecessarily slow because it looks up the symbol table twice for each symbol. - The first hash table lookup/insertion occurs when we instantiate a LazyObject file to insert LazyObject symbols. - The second hash table lookup/insertion occurs when we create an ObjFile from LazyObject file. That overwrites LazyObject symbols with Defined symbols. I think it is not too hard to see how we can now eliminate the second hash table lookup. We can keep LazyObject symbols in Step 1, and then call elf::resolveSymbol() to do Step 2. Differential Revision: https://reviews.llvm.org/D61898 llvm-svn: 360975
* Simplify SymbolTable::add{Defined,Undefined,...} functions.Rui Ueyama2019-05-161-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | SymbolTable's add-family functions have lots of parameters because when they have to create a new symbol, they forward given arguments to Symbol's constructors. Therefore, the functions take at least as many arguments as their corresponding constructors. This patch simplifies the add-family functions. Now, the functions take a symbol instead of arguments to construct a symbol. If there's no existing symbol, a given symbol is memcpy'ed to the symbol table. Otherwise, the functions attempt to merge the existing and a given new symbol. I also eliminated `CanOmitFromDynSym` parameter, so that the functions take really one argument. Symbol classes are trivially constructible, so looks like constructing them to pass to add-family functions is as cheap as passing a lot of arguments to the functions. A quick benchmark showed that this patch seems performance-neutral. This is a preparation for http://lists.llvm.org/pipermail/llvm-dev/2019-April/131902.html Differential Revision: https://reviews.llvm.org/D61855 llvm-svn: 360838
* [LLD][ELF] Add the -z ifunc-noplt optionFangrui Song2019-05-141-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Mark Johnston! Summary: When the option is configured, ifunc calls do not go through the PLT; rather, they appear as regular function calls with relocations referencing the ifunc symbol, and the resolver is invoked when applying the relocation. This is intended for use in freestanding environments where text relocations are permissible and is incompatible with the -z text option. The option is motivated by ifunc usage in the FreeBSD kernel, where ifuncs are used to elide CPU feature flag bit checks in hot paths. Instead of replacing the cost of a branch with that of an indirect function call, the -z ifunc-noplt option is used to ensure that ifunc calls carry no hidden overhead relative to normal function calls. Test Plan: I added a couple of regression tests and tested the FreeBSD kernel build using the latest lld sources. To demonstrate the effects of the change, I used a micro-benchmark which results in frequent invocations of a FreeBSD kernel ifunc. The benchmark was run with and without IBRS enabled, and with and without -zifunc-noplt configured. The observed speedup is small and consistent, and is significantly larger with IBRS enabled: https://people.freebsd.org/~markj/ifunc-noplt/noibrs.txt https://people.freebsd.org/~markj/ifunc-noplt/ibrs.txt Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D61613 llvm-svn: 360685
* [PPC64] toc-indirect to toc-relative relaxationFangrui Song2019-05-071-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [LLD] Emit dynamic relocations for references to script symbols in -pie linksBen Dunbobbin2019-05-011-5/+5
| | | | | | | | | | https://reviews.llvm.org/D55423 caused LLD to stop emitting dynamic relocations for references to script symbols in -pie links. This patch fixes that regression. https://reviews.llvm.org/D61298 llvm-svn: 359683
* [PPC64] Allow R_PPC64_DTPREL* to preemptable local-dynamic symbolsFangrui Song2019-04-231-2/+1
| | | | | | | | Similar to D60945. Differential Revision: https://reviews.llvm.org/D60994 llvm-svn: 358950
* Use llvm::stable_sortFangrui Song2019-04-231-8/+8
| | | | | | | | | Make some small adjustment while touching the code: make parameters const, use less_first(), etc. Differential Revision: https://reviews.llvm.org/D60989 llvm-svn: 358943
* [ELF][X86] Allow R_386_TLS_LDO_32 and R_X86_64_DTPOFF{32,64} to preemptable ↵Fangrui Song2019-04-221-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | local-dynamic symbols Summary: Fixes PR35242. A simplified reproduce: thread_local int i; int f() { return i; } % {g++,clang++} -fPIC -shared -ftls-model=local-dynamic -fuse-ld=lld a.cc ld.lld: error: can't create dynamic relocation R_X86_64_DTPOFF32 against symbol: i in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output In isStaticLinkTimeConstant(), Syn.IsPreemptible is true, so it is not seen as a constant. The error is then issued in processRelocAux(). A symbol of the local-dynamic TLS model cannot be preempted but it can preempt symbols of the global-dynamic TLS model in other DSOs. So it makes some sense that the variable is not static. This patch fixes the linking error by changing getRelExpr() on R_386_TLS_LDO_32 and R_X86_64_DTPOFF{32,64} from R_ABS to R_DTPREL. R_PPC64_DTPREL_* and R_MIPS_TLS_DTPREL_* need similar fixes, but they are not handled in this patch. As a bonus, we use `if (Expr == R_ABS && !Config->Shared)` to find ld-to-le opportunities. R_ABS is overloaded here for such STT_TLS symbols. A dedicated R_DTPREL is clearer. Differential Revision: https://reviews.llvm.org/D60945 llvm-svn: 358870
* [LLD][ELF] - A fix for "linker script assignment loses relative nature of ↵George Rimar2019-04-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | section" bug. This is https://bugs.llvm.org//show_bug.cgi?id=39857. I added the comment with much more details to the bug page, the short version is below. The following script and code demonstrates the issue: aliasto__text = __text; SECTIONS { .text 0x1000 : { __text = . ; *(.text) } } ... call aliasto__text LLD fails with "cannot refer to absolute symbol: aliasto__text" error. It happens because at the moment of scanning the relocations we do not yet assign the correct/final/any section value for the symbol aliasto__text. I made a change to Relocations.cpp to fix that. Also, I had to remove the symbol-location.s test case completely, because now it does not trigger any error. Since now all linker scripts symbols are resolved to constants, no errors can be triggered at all it seems. I checked that it is consistent with the behavior of bfd and gold (they do not trigger errors for the case from symbol-location.s), so it should be OK. I.e. at least it is probably not the best possible, but natural behavior we obtained. Differential revision: https://reviews.llvm.org/D55423 llvm-svn: 358652
* ELF: De-template SharedFile. NFCI.Peter Collingbourne2019-04-081-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D60305 llvm-svn: 357925
* ELF: De-template ELFFileBase. NFCI.Peter Collingbourne2019-04-051-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D60304 llvm-svn: 357806
* Replace `typedef A B` with `using B = A`. NFC.Rui Ueyama2019-04-011-2/+2
| | | | | | | | I did this using Perl. Differential Revision: https://reviews.llvm.org/D60003 llvm-svn: 357372
* Inline a trivial function. NFC.Rui Ueyama2019-03-281-1/+3
| | | | | | | I found that hiding this particular actual expression doesn't help readers understand the code. So I remove and inline that function. llvm-svn: 357140
* [ELF] Change GOT*_FROM_END (relative to end(.got)) to GOTPLT* (start(.got.plt))Fangrui Song2019-03-251-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This should address remaining issues discussed in PR36555. Currently R_GOT*_FROM_END are exclusively used by x86 and x86_64 to express relocations types relative to the GOT base. We have _GLOBAL_OFFSET_TABLE_ (GOT base) = start(.got.plt) but end(.got) != start(.got.plt) This can have problems when _GLOBAL_OFFSET_TABLE_ is used as a symbol, e.g. glibc dl_machine_dynamic assumes _GLOBAL_OFFSET_TABLE_ is start(.got.plt), which is not true. extern const ElfW(Addr) _GLOBAL_OFFSET_TABLE_[] attribute_hidden; return _GLOBAL_OFFSET_TABLE_[0]; // R_X86_64_GOTPC32 In this patch, we * Change all GOT*_FROM_END to GOTPLT* to fix the problem. * Add HasGotPltOffRel to denote whether .got.plt should be kept even if the section is empty. * Simplify GotSection::empty and GotPltSection::empty by setting HasGotOffRel and HasGotPltOffRel according to GlobalOffsetTable early. The change of R_386_GOTPC makes X86::writePltHeader simpler as we don't have to compute the offset start(.got.plt) - Ebx (it is constant 0). We still diverge from ld.bfd (at least in most cases) and gold in that .got.plt and .got are not adjacent, but the advantage doing that is unclear. Reviewers: ruiu, sivachandra, espindola Subscribers: emaste, mehdi_amini, arichardson, dexonsmith, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59594 llvm-svn: 356968
* [ELF] De-virtualize findOrphanPos, excludeLibs and handleARMTlsRelocationFangrui Song2019-03-171-2/+1
| | | | llvm-svn: 356331
* [ELF] De-template wrapSymbols, isReserved and addGotEntry. NFCFangrui Song2019-03-151-3/+3
| | | | llvm-svn: 356237
* [LLD][ELF] - Show symbols visibility in "undefined symbol..." error messages.George Rimar2019-03-121-2/+8
| | | | | | | | | This teaches LLD to report visibility when showing undefined symbol errors and fixes https://bugs.llvm.org/show_bug.cgi?id=40770. Differential revision: https://reviews.llvm.org/D58577 llvm-svn: 355909
* Move a function from .h to .cpp and use a shorter name. NFC.Rui Ueyama2019-02-141-25/+55
| | | | llvm-svn: 354054
* Remove a comparator from header and instead use lambdas for simplicity. NFC.Rui Ueyama2019-02-141-1/+3
| | | | llvm-svn: 354052
* ELF: Allow GOT relocs pointing to non-preemptable ifunc to resolve to an ↵Peter Collingbourne2019-02-131-67/+181
| | | | | | | | | | | | | | | | IRELATIVE where possible. Non-GOT non-PLT relocations to non-preemptible ifuncs result in the creation of a canonical PLT, which now takes the identity of the IFUNC in the symbol table. This (a) ensures address consistency inside and outside the module, and (b) fixes a bug where some of these relocations end up pointing to the resolver. Fixes (at least) PR40474 and PR40501. Differential Revision: https://reviews.llvm.org/D57371 llvm-svn: 353981
* [PPC64] Sort .toc sections accessed with small code model relocs.Sean Fertile2019-02-121-2/+10
| | | | | | | | | | | | | 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
* [ELF] Delete a comment that is no longer correct. Fix a typo. NFCFangrui Song2019-02-091-1/+1
| | | | llvm-svn: 353605
* [PPC64] Set the number of relocations processed for R_PPC64_TLS[GL]D to 2Fangrui Song2019-02-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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/+3
| | | | | | | | | | | | | | | | | | | | | | | 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-3/+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/+3
| | | | | | | | | | | | | | | | | | | 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
* [ELF][AArch64] Add R_AARCH64_PLT_PAGE_PC to isRelExprPeter Smith2019-01-161-1/+1
| | | | | | | | | | | | | | | | | | As a follow on to D56666 (r351186) there is a case when taking the address of an ifunc when linking -pie that can generate a spurious can't create dynamic relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol in readonly segment. Specifically the case is where the ifunc is in the same translation unit as the address taker, so given -fpie the compiler knows the ifunc is defined in the executable so it can use a non-got-generating relocation. The error message is due to R_AARCH64_PLT_PAGE_PC not being added to isRelExpr, its non PLT equivalent R_AARCH64_PAGE_PC is already in isRelExpr. Differential Revision: https://reviews.llvm.org/D56724 llvm-svn: 351335
* [ELF][AArch64] Add missing PLT relocations to isStaticLinkTimeConstantPeter Smith2019-01-151-3/+3
| | | | | | | | | | | | | r347650 fixed pr38074 for AArch64 for static linking. It added two new RelExpr instances R_AARCH64_GOT_PAGE_PC_PLT and R_GOT_PLT. These need to be added to isStaticLinkTimeConstant so that the address of an ifunc can be taken when building a shared library. fixes pr40250 Differential Revision: https://reviews.llvm.org/D56666 llvm-svn: 351186
* keymethod -> keyfunctionFangrui Song2018-12-211-1/+1
| | | | | | Pointed out by ruiu in rLLD349969 llvm-svn: 349974
* Add a doc for missing key function and an error message referencing the doc.Rui Ueyama2018-12-211-0/+4
| | | | | | | | | | | | | | | | Summary: This is a common error, and because many people don't know what the key function is, it is sometimes very confusing. The doc was originally written by Brooks Moses and slightly edited by me. Reviewers: MaskRay, espindola Subscribers: emaste, llvm-commits, arichardson Differential Revision: https://reviews.llvm.org/D55968 llvm-svn: 349941
OpenPOWER on IntegriCloud