summaryrefslogtreecommitdiffstats
path: root/lld/ELF/InputFiles.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [lld] Fix trivial typos in commentsKazuaki Ishizaki2020-01-061-1/+1
| | | | | | Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D72196
* [ELF] Add a comment to handleSectionGroup(). NFCFangrui Song2019-12-121-0/+2
| | | | | | | | Apply suggestion in https://reviews.llvm.org/D71157#1780834 Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D71388
* [ELF] Refine section group --gc-sections rules to not discard .debug_typesFangrui Song2019-12-101-20/+38
| | | | | | | | | | | | | | | | | | | clang/gcc -fdebug-type-sections places .debug_types and .rela.debug_types in a section group, with a signature symbol which represents the type signature. The section group is for deduplication purposes. After D70146, we will discard such section groups. Refine the rule so that we will retain the group if no member has the SHF_ALLOC flag. GNU ld has a similar rule to retain the group if all members have the SEC_DEBUGGING flag. We try to be more general for future-proof purposes: if other non-SHF_ALLOC sections have deduplication needs, they may be placed in a section group. Don't discard them. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D71157
* [ELF] Disallow out-of-range section group indices after D70146Fangrui Song2019-11-191-0/+2
| | | | | Exposed by invalid/sht-group-wrong-section.test http://45.33.8.238/win/2613/step_9.txt
* [ELF] Improve --gc-sections compatibility with GNU ld regarding section groupsFangrui Song2019-11-191-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on D70020 by serge-sans-paille. The ELF spec says: > Furthermore, there may be internal references among these sections that would not make sense if one of the sections were removed or replaced by a duplicate from another object. Therefore, such groups must be included or omitted from the linked object as a unit. A section cannot be a member of more than one group. GNU ld has 2 behaviors that we don't have: - Group members (nextInSectionGroup != nullptr) are subject to garbage collection. This includes non-SHF_ALLOC SHT_NOTE sections. In particular, discarding non-SHF_ALLOC SHT_NOTE sections is an expected behavior by the Annobin project. See https://developers.redhat.com/blog/2018/02/20/annobin-storing-information-binaries/ for more information. - Groups members are retained or discarded as a unit. Members may have internal references that are not expressed as SHF_LINK_ORDER, relocations, etc. It seems that we should be more conservative here: if a section is marked live, mark all the other member within the group. Both behaviors are reasonable. This patch implements them. A new field InputSectionBase::nextInSectionGroup tracks the next member within a group. on ELF64, this increases sizeof(InputSectionBase) froms 144 to 152. InputSectionBase::dependentSections tracks section dependencies, which is used by both --gc-sections and /DISCARD/. We can't overload it for the "next member" semantic, because we should allow /DISCARD/ to discard sections independent of --gc-sections (GNU ld behavior). This behavior may be reasonably used by `/DISCARD/ : { *(.ARM.exidx*) }` or `/DISCARD/ : { *(.note*) }` (new test `linkerscript/discard-group.s`). Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D70146
* Forward declare the DWARFCache to avoid including LLVM DWARF detailsReid Kleckner2019-11-141-0/+1
| | | | | LLD's DWARF.h header leaks a lot of LLVM DWARF includes that LLD doesn't need. For Chunks.cpp, I see a compile time decrease of 3.1s to 2.7s.
* Fix a few typos in lld/ELF to cycle botsNico Weber2019-10-281-1/+1
|
* [ELF] -r: fix crash when processing a SHT_REL[A] that relocates a SHF_MERGE ↵Fangrui Song2019-10-241-10/+10
| | | | | | | | | | | | | | | | | | | | after D67504/r372734 Fix PR43767 In -r mode, when processing a SHT_REL[A] that relocates a SHF_MERGE, sec->getRelocatedSection() is a MergeInputSection and its parent is an OutputSection but is asserted to be a SyntheticSection (MergeSyntheticSection) in LinkerScript.cpp:addInputSec(). ## The code path is not exercised in non -r mode because the relocated section changed from MergeInputSection to InputSection. Reorder the code to make the non -r logic apply to -r as well, thus fix the crash. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D69364
* [LLD] Move duplicated dwarf parsing code to the Common library. NFC.Martin Storsjo2019-10-211-73/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D69197 llvm-svn: 375390
* Improve error message for bad SHF_MERGE sectionsRui Ueyama2019-10-101-5/+8
| | | | | | | | This patch adds a section name to error messages. Differential Revision: https://reviews.llvm.org/D68758 llvm-svn: 374290
* [ELF] Wrap things in `namespace lld { namespace elf {`, NFCFangrui Song2019-10-071-31/+33
| | | | | | | | | | | 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] Set `referenced` bit of Undefined created by BitcodeFileFangrui Song2019-08-301-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | D64136 and D65584, while fixing STB_WEAK issues and improving our compatibility with ld.bfd, can cause another STB_WEAK problem related to LTO: If %tundef.o has an undefined reference on f, and %tweakundef.o has a weak undefined reference on f, %tdef.o has a definition of f ``` ld.lld %tundef.o %tweakundef.o --start-lib %tdef.o --end-lib ``` 1) `%tundef.o` doesn't set the `referenced` bit. 2) `%weakundef.o` changes the binding from STB_GLOBAL to STB_WEAK 3) `%tdef.o` is not fetched because the binding is weak. Step (1) is incorrect. This patch sets the `referenced` bit of Undefined created by bitcode files. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D66992 llvm-svn: 370437
* [LLD] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-1/+1
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368936
* [ELF] Rename odd variable names "New" after r365730. NFCFangrui Song2019-08-131-6/+6
| | | | | | | | | | New -> newSym or newFlags Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D66127 llvm-svn: 368651
* [ELF] Make binding (weak or non-weak) logic consistent for Undefined and ↵Fangrui Song2019-08-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Return early. NFC.Rui Ueyama2019-07-291-10/+10
| | | | llvm-svn: 367200
* ld.lld: Demangle symbols from archives in diagnosticsNico Weber2019-07-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ELF: Allow forward references to linked sections.Peter Collingbourne2019-07-181-17/+21
| | | | | | | | | | | It's possible to create IR that uses !associated to refer to a global that appears later in the module, which can result in these types of forward references being generated. Unfortunately our assembler does not currently accept the resulting .s so I needed to use yaml2obj to test this. Differential Revision: https://reviews.llvm.org/D64880 llvm-svn: 366460
* [ELF] Fix variable names in comments after VariableName -> variableName changeFangrui Song2019-07-161-6/+6
| | | | | | Also fix some typos. llvm-svn: 366181
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-3/+3
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* Re-land "[DebugInfo] Move function from line table to the prologue (NFC)"Jonas Devlieghere2019-07-161-1/+1
| | | | | | | | | | | | | | | | | In LLDB, when parsing type units, we don't need to parse the whole line table. Instead, we only need to parse the "support files" from the line table prologue. To make that possible, this patch moves the respective functions from the LineTable into the Prologue. Because I don't think users of the LineTable should have to know that these files come from the Prologue, I've left the original methods in place, and made them redirect to the LineTable. Differential revision: https://reviews.llvm.org/D64774 llvm-svn: 366164
* [LLD][ELF] - Minor simplification. NFC.George Rimar2019-07-151-4/+6
| | | | | | | | | | | | | | | | | This removes a call to `object::getSymbol<ELFT>`. We used this function in a next way: it was given an array of symbols and index and returned either a symbol at the index given or a error. This function was removed in D64631. (rL366052, but was reverted because of LLD compilation error that I didn't know about). It does not make much sense to keep this function on LLVM side only for LLD, because having only a list of symbols and the index it is not able to produce a valueable error message about context anyways. llvm-svn: 366057
* [Coding style change][lld] Rename variables for non-ELF portsRui Ueyama2019-07-111-9/+9
| | | | | | | | | | | This patch does the same thing as r365595 to other subdirectories, which completes the naming style change for the entire lld directory. With this, the naming style conversion is complete for lld. Differential Revision: https://reviews.llvm.org/D64473 llvm-svn: 365730
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-101-679/+679
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Avoid identifiers that are different only in case. NFC.Rui Ueyama2019-07-031-5/+5
| | | | | | | | 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][RISCV] Support RISC-V in getBitcodeMachineKindKito Cheng2019-07-031-0/+3
| | | | | | | | | | | Add Triple::riscv64 and Triple::riscv32 to getBitcodeMachineKind for get right e_machine during LTO. Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D52165 llvm-svn: 364996
* Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the ↵Fangrui Song2019-06-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ELF][AArch64] Support for BTI and PACPeter Smith2019-06-071-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Branch Target Identification (BTI) and Pointer Authentication (PAC) are architecture features introduced in v8.5a and 8.3a respectively. The new instructions have been added in the hint space so that binaries take advantage of support where it exists yet still run on older hardware. The impact of each feature is: BTI: For executable pages that have been guarded, all indirect branches must have a destination that is a BTI instruction of the appropriate type. For the static linker, this means that PLT entries must have a "BTI c" as the first instruction in the sequence. BTI is an all or nothing property for a link unit, any indirect branch not landing on a valid destination will cause a Branch Target Exception. PAC: The dynamic loader encodes with PACIA the address of the destination that the PLT entry will load from the .plt.got, placing the result in a subset of the top-bits that are not valid virtual addresses. The PLT entry may authenticate these top-bits using the AUTIA instruction before branching to the destination. Use of PAC in PLT sequences is a contract between the dynamic loader and the static linker, it is independent of whether the relocatable objects use PAC. BTI and PAC are independent features that can be combined. So we can have several combinations of PLT: - Standard with no BTI or PAC - BTI PLT with "BTI c" as first instruction. - PAC PLT with "AUTIA1716" before the indirect branch to X17. - BTIPAC PLT with "BTI c" as first instruction and "AUTIA1716" before the first indirect branch to X17. The use of BTI and PAC in relocatable object files are encoded by feature bits in the .note.gnu.property section in a similar way to Intel CET. There is one AArch64 specific program property GNU_PROPERTY_AARCH64_FEATURE_1_AND and two target feature bits defined: - GNU_PROPERTY_AARCH64_FEATURE_1_BTI -- All executable sections are compatible with BTI. - GNU_PROPERTY_AARCH64_FEATURE_1_PAC -- All executable sections have return address signing enabled. Due to the properties of FEATURE_1_AND the static linker can tell when all input relocatable objects have the BTI and PAC feature bits set. The static linker uses this to enable the appropriate PLT sequence. Neither -> standard PLT GNU_PROPERTY_AARCH64_FEATURE_1_BTI -> BTI PLT GNU_PROPERTY_AARCH64_FEATURE_1_PAC -> PAC PLT Both properties -> BTIPAC PLT In addition to the .note.gnu.properties there are two new command line options: --force-bti : Act as if all relocatable inputs had GNU_PROPERTY_AARCH64_FEATURE_1_BTI and warn for every relocatable object that does not. --pac-plt : Act as if all relocatable inputs had GNU_PROPERTY_AARCH64_FEATURE_1_PAC. As PAC is a contract between the loader and static linker no warning is given if it is not present in an input. Two processor specific dynamic tags are used to communicate that a non standard PLT sequence is being used. DTI_AARCH64_BTI_PLT and DTI_AARCH64_BTI_PAC. Differential Revision: https://reviews.llvm.org/D62609 llvm-svn: 362793
* Revert "Revert "Reland D61583 [ELF] Error on relocations to STT_SECTION ↵Sean Fertile2019-06-061-0/+3
| | | | | | | | | | 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-3/+0
| | | | | | | | | | the sections were discarded" This reverts commit 5d3b3188f722456a6470c7effcacf17656406429. Breaks the PowerPC multi-stage buildbot. llvm-svn: 362739
* [lld] Explicitly ignore comdat groups when parsing LTO object(s)Sam Clegg2019-06-051-21/+14
| | | | | | | | | | | | | Any symbols defined in the LTO object are by definition the ones we want in the final output so we skip the comdat group checking in those cases. This change makes the ELF code more explicit about this and means that wasm and ELF do this in the same way. Differential Revision: https://reviews.llvm.org/D62884 llvm-svn: 362625
* [ELF] Allow reading of more than one FEATURE_1_AND in same object.Peter Smith2019-06-051-5/+7
| | | | | | | | | | | | | Although many relocatable objects will have a single GNU_PROPERTY_X86_FEATURE_1_AND in the .note.gnu.property section it is permissible to have more than one, and there are tests in ld.bfd that use it. The behavior that ld.bfd follows is to set the feature bit for a relocatable object if any of the GNU_PROPERTY_X86_FEATURE_1_AND have the feature bit set. Differential Revision: https://reviews.llvm.org/D62862 llvm-svn: 362591
* Read .note.gnu.property sections and emit a merged .note.gnu.property section.Rui Ueyama2019-06-051-0/+77
| | | | | | | | | | | | | This patch also adds `--require-cet` option for the sake of testing. The actual feature for IBT-aware PLT is not included in this patch. This is a part of https://reviews.llvm.org/D59780. Submitting this first should make it easy to work with a related change (https://reviews.llvm.org/D62609). Differential Revision: https://reviews.llvm.org/D62853 llvm-svn: 362579
* Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the ↵Fangrui Song2019-05-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+0
| | | | | | | | | | 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-0/+3
| | | | | | | | | | | | | | | | | | | 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
* Merge ELFFileBase::{initSymtab,parseHeader} as ELFFileBase:init. NFC.Rui Ueyama2019-05-281-71/+59
| | | | | | | | This patch simplifies ELFFile instance initialization by merging two similar functions into a single function and call it from the ctor. llvm-svn: 361789
* Remove elf::createSharedFile and move its code to SharedFile's ctor. NFC.Rui Ueyama2019-05-271-52/+48
| | | | llvm-svn: 361747
* Simplify InputFile::fetch().Rui Ueyama2019-05-231-6/+7
| | | | | | | We don't have to return a value from the function. Instead, we can directly call parseFile from the functions. llvm-svn: 361478
* Remove LazyObjFile::AddedToLink.Rui Ueyama2019-05-231-11/+7
| | | | | | | Instead we can just clear a MemoryBuffer so that we cannot get the same buffer more than once. llvm-svn: 361477
* Move code for symbol resolution from SymbolTable.cpp to Symbols.cpp.Rui Ueyama2019-05-231-12/+11
| | | | | | | | | | | | | | | | 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
* Speed up --start-lib and --end-lib.Rui Ueyama2019-05-231-57/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --{start,end}-lib give files grouped by the options the archive file semantics. That is, each object file between them acts as if it were in an archive file whose sole member is the file. Therefore, files between --{start,end}-lib are linked to the final output only if they are needed to resolve some undefined symbols. Previously, the feature was implemented this way: 1. We read a symbol table and insert defined symbols to the symbol table as lazy symbols. 2. If an undefind symbol is resolved to a lazy symbol, that lazy symbol instantiate ObjFile class for that symbol, which re-insert all defined symbols to the symbol table. So, if an ObjFile is instantiated, defined symbols are inserted to the symbol table twice. Since inserting long symbol names is not cheap, there's a room to optimize here. This patch optimzies it. Now, LazyObjFile remembers symbol handles and passed them over to a new ObjFile instance, so that the ObjFile doesn't insert the same strings. Here is a quick benchmark to link clang. "Original" is the original lld with unmodified command line options. For "Case 1" and "Case 2", I extracted all files from archive files and replace .a's in a command line with .o's wrapped with --{start,end}-lib. I used the original lld for Case 1" and use this patch for Case 2. Original: 5.892 Case 1: 6.001 (+1.8%) Case 2: 5.701 (-3.2%) So, interestingly, --{start,end}-lib are now faster than the regular linking scheme with archive files. That's perhaps not too surprising, though, because for regular archive files, we look up the symbol table with the same string twice. Differential Revision: https://reviews.llvm.org/D62188 llvm-svn: 361473
* [ELF] Improve error message for relocations to symbols defined in discarded ↵Fangrui Song2019-05-221-17/+24
| | | | | | | | | | | | | | | | | | | | | 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
* Simplify the logic to instantiate Symbols. Should be NFC.Rui Ueyama2019-05-221-5/+3
| | | | llvm-svn: 361350
* [ELF] Implement Dependent Libraries FeatureBen Dunbobbin2019-05-171-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements a limited form of autolinking primarily designed to allow either the --dependent-library compiler option, or "comment lib" pragmas ( https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically add the specified library to the link when processing the input file generated by the compiler. Currently this extension is unique to LLVM and LLD. However, care has been taken to design this feature so that it could be supported by other ELF linkers. The design goals were to provide: - A simple linking model for developers to reason about. - The ability to to override autolinking from the linker command line. - Source code compatibility, where possible, with "comment lib" pragmas in other environments (MSVC in particular). Dependent library support is implemented differently for ELF platforms than on the other platforms. Primarily this difference is that on ELF we pass the dependent library specifiers directly to the linker without manipulating them. This is in contrast to other platforms where they are mapped to a specific linker option by the compiler. This difference is a result of the greater variety of ELF linkers and the fact that ELF linkers tend to handle libraries in a more complicated fashion than on other platforms. This forces us to defer handling the specifiers to the linker. In order to achieve a level of source code compatibility with other platforms we have restricted this feature to work with libraries that meet the following "reasonable" requirements: 1. There are no competing defined symbols in a given set of libraries, or if they exist, the program owner doesn't care which is linked to their program. 2. There may be circular dependencies between libraries. The binary representation is a mergeable string section (SHF_MERGE, SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES (0x6fff4c04). The compiler forms this section by concatenating the arguments of the "comment lib" pragmas and --dependent-library options in the order they are encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs sections with the normal mergeable string section rules. As an example, #pragma comment(lib, "foo") would result in: .section ".deplibs","MS",@llvm_dependent_libraries,1 .asciz "foo" For LTO, equivalent information to the contents of a the .deplibs section can be retrieved by the LLD for bitcode input files. LLD processes the dependent library specifiers in the following way: 1. Dependent libraries which are found from the specifiers in .deplibs sections of relocatable object files are added when the linker decides to include that file (which could itself be in a library) in the link. Dependent libraries behave as if they were appended to the command line after all other options. As a consequence the set of dependent libraries are searched last to resolve symbols. 2. It is an error if a file cannot be found for a given specifier. 3. Any command line options in effect at the end of the command line parsing apply to the dependent libraries, e.g. --whole-archive. 4. The linker tries to add a library or relocatable object file from each of the strings in a .deplibs section by; first, handling the string as if it was specified on the command line; second, by looking for the string in each of the library search paths in turn; third, by looking for a lib<string>.a or lib<string>.so (depending on the current mode of the linker) in each of the library search paths. 5. A new command line option --no-dependent-libraries tells LLD to ignore the dependent libraries. Rationale for the above points: 1. Adding the dependent libraries last makes the process simple to understand from a developers perspective. All linkers are able to implement this scheme. 2. Error-ing for libraries that are not found seems like better behavior than failing the link during symbol resolution. 3. It seems useful for the user to be able to apply command line options which will affect all of the dependent libraries. There is a potential problem of surprise for developers, who might not realize that these options would apply to these "invisible" input files; however, despite the potential for surprise, this is easy for developers to reason about and gives developers the control that they may require. 4. This algorithm takes into account all of the different ways that ELF linkers find input files. The different search methods are tried by the linker in most obvious to least obvious order. 5. I considered adding finer grained control over which dependent libraries were ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this is not necessary: if finer control is required developers can fall back to using the command line directly. RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html. Differential Revision: https://reviews.llvm.org/D60274 llvm-svn: 360984
* Move symbol resolution code out of SymbolTable class.Rui Ueyama2019-05-171-20/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [LTO] Improve readability of module IDsIgor Kudrin2019-05-161-4/+5
| | | | | | | | | Module IDs can appear in diagnostic messages. This patch adds some auxiliary symbols to improve their readability. Differential Revision: https://reviews.llvm.org/D61857 llvm-svn: 360858
* Pemove SymbolTable::addBitcode as it is redundant.Rui Ueyama2019-05-161-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D61897 llvm-svn: 360846
* De-template parseFile() and SymbolTable's add-family functions.Rui Ueyama2019-05-161-22/+30
| | | | | | Differential Revision: https://reviews.llvm.org/D61896 llvm-svn: 360844
OpenPOWER on IntegriCloud