summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Symbols.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [ELF] --no-dynamic-linker: don't emit undefined weak symbols to .dynsymFangrui Song2020-01-231-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | I felt really sad to push this commit for my selfish purpose to make glibc -static-pie build with lld. Some code constructs in glibc require R_X86_64_GOTPCREL/R_X86_64_REX_GOTPCRELX referencing undefined weak to be resolved to a GOT entry not relocated by R_X86_64_GLOB_DAT (GNU ld behavior), e.g. csu/libc-start.c if (__pthread_initialize_minimal != NULL) __pthread_initialize_minimal (); elf/dl-object.c void _dl_add_to_namespace_list (struct link_map *new, Lmid_t nsid) { /* We modify the list of loaded objects. */ __rtld_lock_lock_recursive (GL(dl_load_write_lock)); Emitting a GLOB_DAT will make the address equal &__ehdr_start (true value) and cause elf/ldconfig to segfault. glibc really should move away from weak references, which do not have defined semantics. Temporarily special case --no-dynamic-linker. (cherry picked from commit 0fbf28f7aae0ceb70071cac56de345e3ff04439c)
* [ELF] Fix includeInDynsym() when an undefined weak is merged with a lazy ↵Fangrui Song2020-01-091-1/+3
| | | | | | | | | | | | definition An undefined weak does not fetch the lazy definition. A lazy weak symbol should be considered undefined, and thus preemptible if .dynsym exists. D71795 is not quite an NFC. It errors on an R_X86_64_PLT32 referencing an undefined weak symbol. isPreemptible is false (incorrect) => R_PLT_PC is optimized to R_PC => in isStaticLinkTimeConstant, an error is emitted when an R_PC is applied on an undefined weak (considered absolute).
* [ELF] Don't special case weak symbols for pie with no shared objectsFangrui Song2020-01-081-5/+0
| | | | | | | | | | | | | | | | | | | | | | D59275 added the following clause to Symbol::includeInDynsym() if (isUndefWeak() && Config->Pie && SharedFiles.empty()) return false; D59549 explored the possibility to generalize it for -no-pie. GNU ld's rules are architecture dependent and partly controlled by -z {,no-}dynamic-undefined-weak. Our attempts to mimic its rules are actually half-baked and don't provide perceivable benefits (it can save a few more weak undefined symbols in .dynsym in a -static-pie executable). Let's just delete the rule for simplicity. We will expect cosmetic inconsistencies with ld.bfd in certain -static-pie scenarios. This permits a simplification in D71795. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D71794
* [ELF] Add IpltSectionFangrui Song2019-12-171-3/+5
| | | | | | | | | | | | | | | | | | | 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] Update st_size when merging a common symbol with a shared symbolFangrui Song2019-12-131-1/+18
| | | | | | | | | | | | | | | | | | When a common symbol is merged with a shared symbol, increase st_size if the shared symbol has a larger st_size. At runtime, the executable's symbol overrides the shared symbol. The shared symbol may be created from common symbols in a previous link. This rule makes sure we pick the largest size among all common symbols. This behavior matches GNU ld. See https://sourceware.org/bugzilla/show_bug.cgi?id=25236 for discussions. A shared symbol does not hold alignment constraints. Ignore the alignment update. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D71161
* [ELF] --icf: do not fold preemptible symbolsFangrui Song2019-12-101-0/+28
| | | | | | | | | | | | | | | Fixes PR44124. A preemptible symbol may refer to a different definition at runtime. When comparing a pair of relocations, if they refer to different symbols, and either symbol is preemptible, the two containing sections should be considered different. gold has a similar rule https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ce97fa81e0c46d216b80b143ad8c02fff6906fef Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D71163
* [ELF][PPC64] Support long branch thunks with addendsFangrui Song2019-12-051-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Wrap things in `namespace lld { namespace elf {`, NFCFangrui Song2019-10-071-17/+18
| | | | | | | | | | | 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
* [LLD] Simplify the demangleItanium function. NFC.Martin Storsjo2019-09-271-2/+1
| | | | | | | | | Instead of returning an optional, just return the input string if demangling fails, as that's what all callers use anyway. Differential Revision: https://reviews.llvm.org/D68015 llvm-svn: 373077
* [ELF] Simplify handling of exportDynamic and isPreemptibleFangrui Song2019-08-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Writer::includeInDynSym(), exportDynamic is used by a Defined with protected or default visibility, to record whether it is required to be exported into .dynsym. It is set when any of the following conditions hold: 1) There is an interposable symbol from a DSO (Undefined or SharedSymbol with default visibility) 2) If -shared or --export-dynamic is specified, any symbol in an object file/bitcode sets this property, unless suppressed by canBeOmittedFromSymbolTable(). 3) --dynamic-list when producing an executable 4) protected symbol from a DSO preempted by copy relocation/canonical PLT when --ignore-{data,function}-address-equality is specified 5) ifunc is exported when -z ifunc-noplt is specified Bullet points 4) and 5) are irrelevant in this patch. Bullet 3) does not play well with 1) and 2). When -shared is specified, exportDynamic of most symbols is true. This makes it incapable to record --dynamic-list marked symbols. We thus have obscure: if (!config->shared) b->exportDynamic = true; else if (b->includeInDynsym()) b->isPreemptible = true; This patch adds another bit `Symbol::inDynamicList` to record 3). We can thus simplify handleDynamicList() by unifying the DSO and executable cases. It also allows us to simplify isPreemptible - now the field is only used in finalizeSections() and later stages. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D66091 llvm-svn: 368659
* [ELF] Remove redundant isDefined() in Symbol::computeBinding() and delete ↵Fangrui Song2019-08-111-3/+2
| | | | | | | | | | | | | | one redundant call site After r367869, VER_NDX_LOCAL can only be assigned to Defined and CommonSymbol. CommonSymbol becomes Defined after replaceCommonSymbols(), thus `versionId == VER_NDX_LOCAL` will imply `isDefined()`. In maybeReportUndefined(), computeBinding() is called when the symbol is unknown to be Undefined. computeBinding() != STB_LOCAL will always be true. llvm-svn: 368536
* [ELF] Remove redundant !isPreemptible in Symbol::computeBinding()Fangrui Song2019-08-111-1/+1
| | | | | | | | | | | | | | !isPreemptible was added in r343668 to fix PR39104: symbols redefined by replaceWithDefined() might be incorrectly considered STB_LOCAL if a version script specified `local: *;`. After r367869 (`config->defaultSymbolVersion` was removed), we will assign VER_NDX_LOCAL to only regular Defined and CommonSymbol, not Defined created by replaceWithDefined() (because scanVersionScript() is called before scanRelocations()). The !isPreemptible is thus redundant and can be deleted. llvm-svn: 368535
* [ELF] Make binding (weak or non-weak) logic consistent for Undefined and ↵Fangrui Song2019-08-061-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SharedSymbol This is a case missed by D64136. If %t1.o has a weak reference on foo, and %t2.so has a non-weak reference on foo: ``` 0. ld.lld %t1.o %t2.so # ok; STB_WEAK; accepted since D64136 1. ld.lld %t2.so %t1.o # undefined symbol: foo; STB_GLOBAL 2. gold %t1.o %t2.so # ok; STB_WEAK 3. gold %t2.so %t1.o # undefined reference to 'foo'; STB_GLOBAL 4. ld.bfd %t1.o %t2.so # undefined reference to `foo'; STB_WEAK 5. ld.bfd %t2.so %t1.o # undefined reference to `foo'; STB_WEAK ``` It can be argued that in both cases, the binding of the undefined foo should be set to STB_WEAK, because the binding should not be affected by referenced from shared objects. --allow-shlib-undefined doesn't suppress errors (3,4,5), but -shared or --noinhibit-exec allows ld.bfd/gold to produce a binary: ``` 3. gold -shared %t2.so %t1.o # ok; STB_GLOBAL 4. ld.bfd -shared %t2.so %t1.o # ok; STB_WEAK 5. ld.bfd -shared %t1.o %t1.o # ok; STB_WEAK ``` If %t2.so has DT_NEEDED entries, ld.bfd will load them (lld/gold don't have the behavior). If one of the DSO defines foo and it is in the link-time search path (e.g. DT_NEEDED entry is an absolute path, via -rpath=, via -rpath-link=, etc), `ld.bfd %t1.o %t2.so` and `ld.bfd %t1.o %t2.so` will not error. In this patch, we make Undefined and SharedSymbol share the same binding computing logic. Case 1 will be allowed: ``` 0. ld.lld %t1.o %t2.so # ok; STB_WEAK; accepted since D64136 1. ld.lld %t2.so %t1.o # ok; STB_WEAK; changed by this patch ``` In the future, we can explore the option that turns both (0,1) into errors if --no-allow-shlib-undefined (default when linking an executable) is in action. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D65584 llvm-svn: 368038
* [ELF] Consistently prioritize non-* wildcards overs "*" in version scriptsFangrui Song2019-08-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We prioritize non-* wildcards overs VER_NDX_LOCAL/VER_NDX_GLOBAL "*". This patch generalizes the rule to "*" of other versions and thus fixes PR40176. I don't feel strongly about this GNU linkers' behavior but the generalization simplifies code. Delete `config->defaultSymbolVersion` which was used to special case VER_NDX_LOCAL/VER_NDX_GLOBAL "*". In `SymbolTable::scanVersionScript`, custom versions are handled the same way as VER_NDX_LOCAL/VER_NDX_GLOBAL. So merge `config->versionScript{Locals,Globals}` into `config->versionDefinitions`. Overall this seems to simplify the code. In `SymbolTable::assign{Exact,Wildcard}Versions`, `sym->verdefIndex == config->defaultSymbolVersion` is changed to `verdefIndex == UINT32_C(-1)`. This allows us to give duplicate assignment diagnostics for `{ global: foo; };` `V1 { global: foo; };` In test/linkerscript/version-script.s: vs_index of an undefined symbol changes from 0 to 1. This doesn't matter (arguably 1 is better because the binding is STB_GLOBAL) because vs_index of an undefined symbol is ignored. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D65716 llvm-svn: 367869
* [ELF] Simplify with dyn_cast_or_null. NFCFangrui Song2019-07-261-1/+1
| | | | llvm-svn: 367126
* ld.lld: Demangle symbols from archives in diagnosticsNico Weber2019-07-231-11/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | This ports r366573 from COFF to ELF. There are now to toString(Archive::Symbol), one doing MSVC demangling in COFF and one doing Itanium demangling in ELF, so rename these two to toCOFFString() and to toELFString() to not get a duplicate symbol. Nothing ever passes a raw Archive::Symbol to CHECK(), so these not being part of the normal toString() machinery seems ok. There are two code paths in the ELF linker that emits this type of diagnostic: 1. The "normal" one in InputFiles.cpp. This is covered by the tweaked test. 2. An additional one that's only used for libcalls if there's at least one bitcode in the link, and if the libcall symbol is lazy, and lazily loaded from an archive (i.e. not from a lazy .o file). (This code path was added in r339301.) Since all libcall names so far are C symbols and never mangled, the change there is not observable and hence not covered by tests. Differential Revision: https://reviews.llvm.org/D65095 llvm-svn: 366836
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-101-253/+253
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] resolveUndefined: ignore undefined symbols in SharedFile for Undefined ↵Fangrui Song2019-07-041-12/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and SharedSymbol If %t1.o has a weak reference on foo, and %t2.so has a non-weak reference on foo: `ld.lld %t1.o %t2.so -o %t` We incorrectly set the binding of the undefined foo to STB_GLOBAL. Fix this by ignoring undefined symbols in a SharedFile for Undefined and SharedSymbol. This fixes the binding of pthread_once when the program links against both librt.so and libpthread.so ``` a.o: STB_WEAK reference to pthread_once librt.so: STB_GLOBAL reference to pthread_once # should be ignored libstdc++.so: STB_WEAK reference to pthread_once # should be ignored libgcc_s.so.1: STB_WEAK reference to pthread_once # should be ignored ``` The STB_GLOBAL pthread_once issue (not fixed by D63974) can cause a link error when the result DSO is used to link another DSO with -z defs if -lpthread is not specified. (libstdc++.so.6 not having a dependency on libpthread.so is a really nasty hack...) We happened to create a weak undef before D63974 because libgcc_s.so.1 was linked the last and it changed the binding again to weak. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64136 llvm-svn: 365129
* Avoid identifiers that are different only in case. NFC.Rui Ueyama2019-07-031-6/+6
| | | | | | | | Some variables in lld have the same name as functions ignoring case. This patch gives them different names, so that my next patch is easier to read. llvm-svn: 365003
* [ELF] Only allow the binding of SharedSymbol to change for the first undef refFangrui Song2019-07-021-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PR42442 t.o has a STB_GLOBAL undef ref to f t2.so has a STB_WEAK undef ref to f t1.so defines f ld.lld t.o t1.so t2.so currently sets the binding of `f` to STB_WEAK. This is not correct because there exists a STB_GLOBAL undef ref from a regular object. The problem is that resolveUndefined() doesn't check if the undef ref is seen for the first time: if (isShared() || isLazy() || (isUndefined() && Other.Binding != STB_WEAK)) Binding = Other.Binding; The isShared() condition should be `isShared() && !Referenced` where Referenced is set to true after an undef ref is seen. In practice, when linking a pthread program with glibc: // a.o #include <pthread.h> pthread_mutex_t mu = PTHREAD_MUTEX_INITIALIZER; int main() { pthread_mutex_unlock(&mu); } {clang,gcc} -fuse-ld=lld a.o -lpthread # libpthread.so is linked before libgcc_s.so.1 The weak undef pthread_mutex_unlock in libgcc_s.so.1 makes the result weak, which diverges from GNU linkers where STB_DEFAULT is used: 23: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_lock (Note, if -pthread is used instead, libpthread.so will be linked **after** libgcc_s.so.1 . lld sets the binding to the expected STB_GLOBAL) Similar linking sequences (ld.lld t.o t1.so t2.so) appear to be used by Go, which cause a build error https://github.com/golang/go/issues/31912. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D63974 llvm-svn: 364913
* Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the ↵Fangrui Song2019-06-261-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sections were discarded This restores r361830 "[ELF] Error on relocations to STT_SECTION symbols if the sections were discarded" and dependent commits (r362218, r362497) which were reverted by r364321, with a fix of a --gdb-index issue. .rela.debug_ranges contains relocations of range list entries: // start address of a range list entry // old: 0; after r361830: 0 00000000000033a0 R_X86_64_64 .text._ZN2v88internal7Isolate7factoryEv + 0 // end address of a range list entry // old: 0xe; after r361830: 0 00000000000033a8 R_X86_64_64 .text._ZN2v88internal7Isolate7factoryEv + e If both start and end addresses of a range list entry resolve to 0, DWARFDebugRangeList::isEndOfListEntry() will return true, then the .debug_range decoding loop will terminate prematurely: while (true) { decode StartAddress decode EndAddress if (Entry.isEndOfListEntry()) // prematurely break; Entries.push_back(Entry); } In lld/ELF/SyntheticSections.cpp, readAddressAreas() will read incomplete address ranges and the resulting .gdb_index will be incomplete. For files that gdb hasn't loaded their debug info, gdb uses .gdb_index to map addresses to CUs. The absent entries make gdb fail to symbolize some addresses. To address this issue, we simply allow relocations to undefined symbols in DWARF.cpp:findAux() and let RelocationResolver resolve them. This patch should fix: [1] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190603/659848.html [2] https://bugs.chromium.org/p/chromium/issues/detail?id=978067 llvm-svn: 364391
* Revert r362743 "Revert "Revert "Reland D61583 [ELF] Error on relocations to ↵Hans Wennborg2019-06-251-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | STT_SECTION symbols if the sections were discarded""" (In effect, reverting "[ELF] Error on relocations to STT_SECTION symbols if the sections were discarded".) It caused debug info problems in LibreOffice [1] and Chromium/V8 [2]. Reverting until those can be fixed. It also reverts r362497 "STT_SECTION symbol should be defined" on .eh_frame, .debug*, .zdebug* and .gcc_except_table" which was landed as a follow-up to the above. > With -r or --emit-relocs, we warn `STT_SECTION symbol should be defined` > on relocations to discarded section symbol. This was added as an error > in rLLD319404, but was not so effective before D61583 (it turned the > error to a warning). > > Relocations from .eh_frame .debug* .zdebug* .gcc_except_table to > discarded .text are very common and somewhat expected. Don't warn/error > on them. As a reference, ld.bfd has a similar logic in > _bfd_elf_default_action_discarded() to allow these cases. > > Delete invalid-undef-section-symbol.test because what it intended to > check is now covered by the updated comdat-discarded-reloc.s > > Delete relocatable-eh-frame.s because we allow relocations from > .eh_frame as a special case now. And finally it reverts r362218 "[ELF] Replace a dead test in getSymVA() with assert()" as that also depended on the main change reverted here. > Symbols relative to discarded comdat sections are Undefined instead of > Defined now (after D59649 and D61583). The `== &InputSection::Discarded` > test becomes dead. I cannot find a test related to this behavior. [1] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190603/659848.html [2] https://bugs.chromium.org/p/chromium/issues/detail?id=978067 llvm-svn: 364321
* Fix an issue that common symbols are not internalized under some condition.Rui Ueyama2019-06-251-3/+3
| | | | | | | | | | | | | | | | | | | | r360841 introduced CommonSymbol class. An unintended behavioral change introduced by that change was that common symbols are not internalized by LTO under some condition. This patch fixes that issue. The issue occurred under the following condition: 1. There exists a common symbol 2. At least one DSO is given to lld or -pie is used If the above conditions are met, Symbol::includeInDynsym() returned a wrong value for a common symbol. Fixes https://bugs.llvm.org/show_bug.cgi?id=41978 Differential Revision: https://reviews.llvm.org/D63752 llvm-svn: 364273
* [ELF][RISCV] Create dummy .sdata for __global_pointer$ if .sdata does not existFangrui Song2019-06-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | If .sdata is absent, linker synthesized __global_pointer$ gets a section index of SHN_ABS. (ld.bfd has a similar issue: binutils PR24678) Scrt1.o may use `lla gp, __global_pointer$` to reference the symbol PC relatively. In -pie/-shared mode, lld complains if a PC relative relocation references an absolute symbol (SHN_ABS) but ld.bfd doesn't: ld.lld: error: relocation R_RISCV_PCREL_HI20 cannot refer to lute symbol: __global_pointer$ Let the reference of __global_pointer$ to force creation of .sdata to fix the problem. This is similar to _GLOBAL_OFFSET_TABLE_, which forces creation of .got or .got.plt . Also, change the visibility from STV_HIDDEN to STV_DEFAULT and don't define the symbol for -shared. This matches ld.bfd, though I don't understand why it uses STV_DEFAULT. Reviewed By: ruiu, jrtc27 Differential Revision: https://reviews.llvm.org/D63132 llvm-svn: 363351
* [ELF] Delete GotEntrySize and GotPltEntrySizeFangrui Song2019-05-311-7/+5
| | | | | | | | | | | | | 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
* [ELF] Replace a dead test in getSymVA() with assert()Fangrui Song2019-05-311-7/+1
| | | | | | | | | | | | Symbols relative to discarded comdat sections are Undefined instead of Defined now (after D59649 and D61583). The `== &InputSection::Discarded` test becomes dead. I cannot find a test related to this behavior. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62725 llvm-svn: 362218
* [ELF] Implement Local Dynamic style TLSDESC for x86-64Fangrui Song2019-05-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | For the Local Dynamic case of TLSDESC, _TLS_MODULE_BASE_ is defined as a special TLS symbol that makes: 1) Without relaxation: it produces a dynamic TLSDESC relocation that computes 0. Adding @dtpoff to access a TLS symbol. 2) With LD->LE relaxation: _TLS_MODULE_BASE_@tpoff = 0 (lowest address in the TLS block). Adding @tpoff to access a TLS symbol. For 1), this saves dynamic relocations and GOT slots as otherwise (General Dynamic) we would create an R_X86_64_TLSDESC and reserve two GOT slots for each symbol. Add ElfSym::TlsModuleBase and change the signature of getTlsTpOffset() to special case _TLS_MODULE_BASE_. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62577 llvm-svn: 362078
* ELF: Add basic partition data structures and behaviours.Peter Collingbourne2019-05-291-1/+1
| | | | | | | | | | | | | | This change causes us to read partition specifications from partition specification sections and split output sections into partitions according to their reachability from partition entry points. This is only the first step towards a full implementation of partitions. Later changes will add additional synthetic sections to each partition so that they can be loaded independently. Differential Revision: https://reviews.llvm.org/D60353 llvm-svn: 361925
* [lld] Trace all references with lld --trace-symbolSam Clegg2019-05-241-1/+4
| | | | | | | | | | | Previously undefined symbol references were only traced if they were seen before that definition. Fixes https://bugs.llvm.org/show_bug.cgi?id=41878 Differential Revision: https://reviews.llvm.org/D61929 llvm-svn: 361636
* Simplify InputFile::fetch().Rui Ueyama2019-05-231-4/+2
| | | | | | | We don't have to return a value from the function. Instead, we can directly call parseFile from the functions. llvm-svn: 361478
* Move code for symbol resolution from SymbolTable.cpp to Symbols.cpp.Rui Ueyama2019-05-231-6/+310
| | | | | | | | | | | | | | | | My recent commits separated symbol resolution from the symbol table, so the functions to resolve symbols are now in a somewhat wrong file. This patch moves it to Symbols.cpp. The functions are now member functions of the symbol. This is code move change. I modified function names so that they are appropriate as member functions, though. No functionality change intended. Differential Revision: https://reviews.llvm.org/D62290 llvm-svn: 361474
* Introduce CommonSymbol.Rui Ueyama2019-05-161-1/+3
| | | | | | | | | | | | | | | | | Previously, we handled common symbols as a kind of Defined symbol, but what we were doing for common symbols is pretty different from regular defined symbols. Common symbol and defined symbol are probably as different as shared symbol and defined symbols are different. This patch introduces CommonSymbol to represent common symbols. After symbols are resolved, they are converted to Defined symbols residing in a .bss section. Differential Revision: https://reviews.llvm.org/D61895 llvm-svn: 360841
* Simplify SymbolTable::add{Defined,Undefined,...} functions.Rui Ueyama2019-05-161-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ELF] Emit weak-undef symbols in .dynsym of a PIE binary only if linked ↵Siva Chandra2019-03-181-0/+4
| | | | | | | | | | | | | | against shared libs. Reviewers: espindola Subscribers: emaste, arichardson, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59275 llvm-svn: 356374
* [MIPS] Handle cross-mode (regular <-> microMIPS) jumpsSimon Atanasyan2019-02-191-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch solves two tasks: 1. MIPS ABI allows to mix regular and microMIPS code and perform cross-mode jumps. Linker needs to detect such cases and replace jump/branch instructions by their cross-mode equivalents. 2. Other tools like dunamic linkers need to recognize cases when dynamic table entries, e_entry field of an ELF header etc point to microMIPS symbol. Linker should provide such information. The first task is implemented in the `MIPS<ELFT>::relocateOne()` method. New routine `fixupCrossModeJump` detects ISA mode change, checks and replaces an instruction. The main problem is how to recognize that relocation target is microMIPS symbol. For absolute and section symbols compiler or assembler set the less-significant bit of the symbol's value or sum of the symbol's value and addend. And this bit signals to linker about microMIPS code. For global symbols compiler cannot do the same trick because other tools like, for example, disassembler wants to know an actual position of the symbol. So compiler sets STO_MIPS_MICROMIPS flag in the `st_other` field. In `MIPS<ELFT>::relocateOne()` method we have a symbol's value only and cannot access any symbol's attributes. To pass type of the symbol (regular/microMIPS) to that routine as well as other places where we write a symbol value as-is (.dynamic section, `Elf_Ehdr::e_entry` field etc) we set when necessary a less-significant bit in the `getSymVA` function. Differential revision: https://reviews.llvm.org/D40147 llvm-svn: 354311
* ELF: Allow GOT relocs pointing to non-preemptable ifunc to resolve to an ↵Peter Collingbourne2019-02-131-3/+7
| | | | | | | | | | | | | | | | 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
* 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
* Do not emit a corrupt symbol table entry for .rela_iplt_{start,end}.Rui Ueyama2019-01-151-0/+1
| | | | | | | | | | | | | If .rela.iplt does not exist, we used to emit a corrupt symbol table that contains two symbols, .rela_iplt_{start,end}, pointing to a nonexisting section. This patch fixes the issue by setting section index 0 to the symbols if .rel.iplt section does not exist. Differential Revision: https://reviews.llvm.org/D56623 llvm-svn: 351218
* Simplify Symbol::getPltVA.Rui Ueyama2018-11-281-11/+2
| | | | | | | | | | | This patch also makes getPltEntryOffset a non-member function because it doesn't depend on any private members of the TargetInfo class. I tried a few different ideas, and it seems this change fits in best to me. Differential Revision: https://reviews.llvm.org/D54981 llvm-svn: 347781
* [ELF] Write IPLT header in -static -z retpolineplt modeFangrui Song2018-11-211-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes PR39711: -static -z retpolineplt does not produce retpoline PLT header. -z now is not relevant. Statically linked executable does not have PLT, but may have IPLT with no header. When -z retpolineplt is specified, however, the repoline PLT header should still be emitted. I've checked that this fixes the FreeBSD reproduce in PR39711 and a Linux program statically linked against glibc. The programm print "Hi" rather than SIGILL/SIGSEGV. getPltEntryOffset may look dirty after this patch, but it can be cleaned up later. Another possible improvement is that when there are non-preemptible IFUNC symbols (rare case, e.g. -Bsymbolic), both In.Plt and In.Iplt can be non-empty and we'll emit the retpoline PLT header twice. Reviewers: espindola, emaste, chandlerc, ruiu Reviewed By: emaste Subscribers: emaste, arichardson, krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D54782 llvm-svn: 347404
* [PPC64] Long branch thunks.Sean Fertile2018-11-141-0/+11
| | | | | | | | | | | | | | | | | | 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
* Rename warnUnorderableSymbol maybeWarnUnorderableSymbol because the function ↵Rui Ueyama2018-10-261-1/+1
| | | | | | doesn't always emit a warning. llvm-svn: 345393
* Remove a global variable that is set but not used.Rui Ueyama2018-10-231-1/+0
| | | | llvm-svn: 345080
* Remove `Type` parameter from SymbolTable::insert(). NFC.Rui Ueyama2018-10-121-0/+2
| | | | | | | | | `Type` parameter was used only to check for TLS attribute mismatch, but we can do that when we actually replace symbols, so we don't need to type as an argument. This change should simplify the interface of the symbol table a bit. llvm-svn: 344394
* [ELF] Don't warn on undefined symbols if UnresolvedPolicy::Ignore is usedFangrui Song2018-10-101-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add a condition UnresolvedPolicy::Ignore to elf::warnUnorderedSymbol to suppress Sym->isUndefined() warnings from both 1) --symbol-ordering-file= 2) .llvm.call-graph-profile If --unresolved-symbols=ignore-all is used, no "undefined symbol" error/warning is emitted. It makes sense to not warn unorderable symbols. Otherwise, If an executable is linked, the default policy UnresolvedPolicy::ErrorOrWarn will issue a "undefined symbol" error. The unorderable symbol warning is redundant. If a shared object is linked, it is possible that only part of object files are used and some symbols are left undefined. The warning is not very necessary. In particular for .llvm.call-graph-profile, when linking a shared object, a call graph profile may contain undefined symbols. This case generated a warning before but it will be suppressed by this patch. Reviewers: ruiu, davidxl, espindola Reviewed By: ruiu Subscribers: grimar, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D53044 llvm-svn: 344195
* [ELF] - Do not forget to include to .dymsym symbols that were converted to ↵George Rimar2018-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Defined. This is the fix for "Bug 39104 - LLD links incorrect ELF executable if version script contains "local: *;" (https://bugs.llvm.org/show_bug.cgi?id=39104). The issue happens when we have non-PIC program call to function in a shared library. (for example, the PR above has R_X86_64_PC32 relocation against __libc_start_main) LLD converts symbol to Defined in that case with the use of replaceWithDefined() The issue is that after above we create a broken relocation because do not include the symbol into .dynsym. That happens when the version script is used because we treat the symbol as STB_LOCAL if the following condition match: VersionId == VER_NDX_LOCAL && isDefined() and do not include it to .dynsym because of that. Patch fixes the issue. Differential revision: https://reviews.llvm.org/D52724 llvm-svn: 343668
* Reset input section pointers to null on each linker invocation.Rui Ueyama2018-09-251-5/+5
| | | | | | | | | | Previously, if you invoke lld's `main` more than once in the same process, the second invocation could fail or produce a wrong result due to a stale pointer values of the previous run. Differential Revision: https://reviews.llvm.org/D52506 llvm-svn: 343009
* [ELF] Set Out::TlsPhdr earlier for encoding packed reloc tablesRyan Prichard2018-09-181-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For --pack-dyn-relocs=android, finalizeSections calls LinkerScript::assignAddresses and AndroidPackedRelocationSection::updateAllocSize in a loop, where assignAddresses lays out the ELF image, then updateAllocSize determines the size of the Android packed relocation table by encoding it. Encoding the table requires knowing the values of relocation addends. To get the addend of a TLS relocation, updateAllocSize can call getSymVA on a TLS symbol before setPhdrs has initialized Out::TlsPhdr, producing an error: <file> has an STT_TLS symbol but doesn't have an SHF_TLS section Fix the problem by initializing Out::TlsPhdr immediately after the program headers are created. The segment's p_vaddr field isn't initialized until setPhdrs, so use FirstSec->Addr, which is what setPhdrs would use. FirstSec will typically refer to the .tdata or .tbss output section, whose (tentative) address was computed by assignAddresses. Android currently avoids this problem because it uses emutls and doesn't support ELF TLS. This problem doesn't apply to --pack-dyn-relocs=relr because SHR_RELR only handles relative relocations without explicit addends or info. Fixes https://bugs.llvm.org/show_bug.cgi?id=37841. Reviewers: ruiu, pcc, chh, javed.absar, espindola Subscribers: emaste, arichardson, llvm-commits, srhines Differential Revision: https://reviews.llvm.org/D51671 llvm-svn: 342432
* [ELF] Revert "Also demote lazy symbols."Chih-Hung Hsieh2018-09-111-1/+2
| | | | | | | | | This reverts commit https://reviews.llvm.org/rL330869 for a regression to link Android dex2oatds. Differential Revision: https://reviews.llvm.org/D51892 llvm-svn: 342007
* Support RISC-VRui Ueyama2018-08-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by PkmX. This patch makes lld recognize RISC-V target and implements basic relocation for RV32/RV64 (and RVC). This should be necessary for static linking ELF applications. The ABI documentation for RISC-V can be found at: https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md. Note that the documentation is far from complete so we had to figure out some details from bfd. The patch should be pretty straightforward. Some highlights: - A new relocation Expr R_RISCV_PC_INDIRECT is added. This is needed as the low part of a PC-relative relocation is linked to the corresponding high part (auipc), see: https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md#pc-relative-symbol-addresses - LLVM's MC support for RISC-V is very incomplete (we are working on this), so tests are given in objectyaml format with the original assembly included in the comments. Once we have complete support for RISC-V in MC, we can switch to llvm-as/llvm-objdump. - We don't support linker relaxation for now as it requires greater changes to lld that is beyond the scope of this patch. Once this is accepted we can start to work on adding relaxation to lld. Differential Revision: https://reviews.llvm.org/D39322 llvm-svn: 339364
OpenPOWER on IntegriCloud