summaryrefslogtreecommitdiffstats
path: root/lld/ELF/InputFiles.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Introduce CommonSymbol.Rui Ueyama2019-05-161-4/+4
| | | | | | | | | | | | | | | | | 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-50/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move SymbolTable::addFile to InputFiles.cpp.Rui Ueyama2019-05-141-0/+87
| | | | | | | | | | | | | | | | | The symbol table used to be a container of vectors of input files, but that's no longer the case because the vectors are moved out of SymbolTable and are now global variables. Therefore, addFile doesn't have to belong to any class. This patch moves the function out of the class. This patch is a preparation for my RFC [1]. [1] http://lists.llvm.org/pipermail/llvm-dev/2019-April/131902.html Differential Revision: https://reviews.llvm.org/D61854 llvm-svn: 360666
* Rename a variable and add a comment.Rui Ueyama2019-04-101-2/+2
| | | | llvm-svn: 358049
* De-template SymbolTable::addShared.Rui Ueyama2019-04-091-2/+5
| | | | | | | Because of r357925, this member function doesn't have to be a template of ELFT. llvm-svn: 357982
* ELF: Move verneed tracking data structures out of VersionNeedSection.Peter Collingbourne2019-04-081-0/+2
| | | | | | | | | | | | | | | | For partitions I intend to use the same set of version indexes in each partition for simplicity. Since each partition will need its own VersionNeedSection this will require moving the verneed tracking out of VersionNeedSection. The way I've done this is to move most of the tracking into SharedFile. What will eventually become the per-partition tracking still lives in VersionNeedSection. As a bonus the code gets a little simpler and more consistent with how we handle verdef. Differential Revision: https://reviews.llvm.org/D60307 llvm-svn: 357926
* ELF: De-template SharedFile. NFCI.Peter Collingbourne2019-04-081-102/+121
| | | | | | Differential Revision: https://reviews.llvm.org/D60305 llvm-svn: 357925
* ELF: De-template ELFFileBase. NFCI.Peter Collingbourne2019-04-051-42/+40
| | | | | | Differential Revision: https://reviews.llvm.org/D60304 llvm-svn: 357806
* ELF: Simplify. NFCI.Peter Collingbourne2019-04-051-7/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D60299 llvm-svn: 357739
* ELF: Move SymtabSHNDX and getSectionIndex() to ObjFile. NFCI.Peter Collingbourne2019-04-041-8/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D60244 llvm-svn: 357670
* [ELF] Print a better error for an archive containing a non-ELF file.Eli Friedman2019-03-121-5/+7
| | | | | | | | | Hopefully gives a more readable error message for the most obvious mistake. Differential Revision: https://reviews.llvm.org/D59170 llvm-svn: 355888
* Include an archive file name in an error message for a corrupted file.Rui Ueyama2019-03-121-7/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D59212 llvm-svn: 355886
* [DebugInfo] add SectionedAddress to DebugInfo interfaces.Alexey Lapshin2019-02-271-2/+13
| | | | | | | | | | | | | | | | | That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703 "wrong line number info for obj file compiled with -ffunction-sections" bug. The problem happened with only .o files. If object file contains several .text sections then line number information showed incorrectly. The reason for this is that DwarfLineTable could not detect section which corresponds to specified address(because address is the local to the section). And as the result it could not select proper sequence in the line table. The fix is to pass SectionIndex with the address. So that it would be possible to differentiate addresses from various sections. With this fix llvm-objdump shows correct line numbers for disassembled code. Differential review: https://reviews.llvm.org/D58194 llvm-svn: 354972
* LLD/AMDGPU: Preserve ABI version during linking ELF for AMDGPUKonstantin Zhuravlyov2019-02-141-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D58026 llvm-svn: 354086
* [ELF] Support --{,no-}allow-shlib-undefinedFangrui Song2019-02-011-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking an executable. This patch implements a check to error on undefined symbols in a shared object, if all of its DT_NEEDED entries are seen. Our approach resembles the one used in gold, achieves a good balance to be useful but not too smart (ld.bfd traces all DSOs and emulates the behavior of a dynamic linker to catch more cases). The error is issued based on the symbol table, different from undefined reference errors issued for relocations. It is most effective when there are DSOs that were not linked with -z defs (e.g. when static sanitizers runtime is used). gold has a comment that some system libraries on GNU/Linux may have spurious undefined references and thus system libraries should be excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The story may have changed now but we make --allow-shlib-undefined the default for now. Its interaction with -shared can be discussed in the future. Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: joerg, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D57385 llvm-svn: 352826
* lld: elf: discard more specific .gnu.linkonce sectionNick Desaulniers2019-01-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: lld discards .gnu.linonce.* sections work around a bug in glibc. https://sourceware.org/bugzilla/show_bug.cgi?id=20543 Unfortunately, the Linux kernel uses a section named .gnu.linkonce.this_module to store infomation about kernel modules. The kernel reads data from this section when loading kernel modules, and errors if it fails to find this section. The current behavior of lld discards this section when kernel modules are linked, so kernel modules linked with lld are unloadable by the linux kernel. The Linux kernel should use a comdat section instead of .gnu.linkonce. The minimum version of binutils supported by the kernel supports comdat sections. The kernel is also not relying on the old linkonce behavior; it seems to have chosen a name that contains a deprecated GNU feature. Changing the section name now in the kernel would require all kernel modules to be recompiled to make use of the new section name. Instead, rather than discarding .gnu.linkonce.*, let's discard the more specific section name to continue working around the glibc issue while supporting linking Linux kernel modules. Link: https://github.com/ClangBuiltLinux/linux/issues/329 Reviewers: pcc, espindola Reviewed By: pcc Subscribers: nathanchance, emaste, arichardson, void, srhines Differential Revision: https://reviews.llvm.org/D57294 llvm-svn: 352302
* Simplify. NFC.Rui Ueyama2019-01-251-4/+2
| | | | llvm-svn: 352242
* Untabify.Rui Ueyama2019-01-241-1/+1
| | | | llvm-svn: 352070
* Partial support of SHT_GROUP without flagSerge Guelton2019-01-241-22/+19
| | | | | | | | | | This does *not* implement full SHT_GROUP semantic, yet it is a simple step forward: Sections within a group are still considered valid, but they do not behave as specified by the standard in case of garbage collection. Differential Revision: https://reviews.llvm.org/D56437 llvm-svn: 352068
* 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
* [LLD][ELF] - Support MSP430.George Rimar2019-01-101-0/+2
| | | | | | | | | | | Patch by Michael Skvortsov! This change adds a basic support for linking static MSP430 ELF code. Implemented relocation types are intended to correspond to the BFD. Differential revision: https://reviews.llvm.org/D56535 llvm-svn: 350819
* Use unique_ptr to manage a TarWriter instance. NFC.Rui Ueyama2018-12-181-1/+1
| | | | llvm-svn: 349581
* [ELF] - Do not crash when -r output uses linker script with `/DISCARD/`George Rimar2018-11-011-2/+10
| | | | | | | | | | | | This is https://bugs.llvm.org/show_bug.cgi?id=39493. We crashed previously because did not handle /DISCARD/ properly when -r was used. I think it is uncommon to use scripts with -r, though I see nothing wrong to handle the /DISCARD/ so that we will not crash at least. Differential revision: https://reviews.llvm.org/D53864 llvm-svn: 345819
* Use llvm::arrayRefFromStringRefSam Clegg2018-10-221-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D53432 llvm-svn: 344888
* Rename SymbolTable::addRegular -> SymbolTable::addDefined.Rui Ueyama2018-10-111-4/+4
| | | | | | | We have addAbsolute, addBitcode, addCommon, etc. addRegular looked a bit inconsistent. llvm-svn: 344294
* Avoid unnecessary buffer allocation and memcpy for compressed sections.Rui Ueyama2018-10-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we uncompress all compressed sections before doing anything. That works, and that is conceptually simple, but that could results in a waste of CPU time and memory if uncompressed sections are then discarded or just copied to the output buffer. In particular, if .debug_gnu_pub{names,types} are compressed and if no -gdb-index option is given, we wasted CPU and memory because we uncompress them into newly allocated bufers and then memcpy the buffers to the output buffer. That temporary buffer was redundant. This patch changes how to uncompress sections. Now, compressed sections are uncompressed lazily. To do that, `Data` member of `InputSectionBase` is now hidden from outside, and `data()` accessor automatically expands an compressed buffer if necessary. If no one calls `data()`, then `writeTo()` directly uncompresses compressed data into the output buffer. That eliminates the redundant memory allocation and redundant memcpy. This patch significantly reduces memory consumption (20 GiB max RSS to 15 Gib) for an executable whose .debug_gnu_pub{names,types} are in total 5 GiB in an uncompressed form. Differential Revision: https://reviews.llvm.org/D52917 llvm-svn: 343979
* [ELF] Fix crash on invalid undefined local symbolsShoaib Meenai2018-10-031-9/+9
| | | | | | | | | | | | | | | | | | | | r320770 made LLD handle invalid DSOs where local symbols were found in the global part of the symbol table. Unfortunately, it didn't handle the case where those local symbols were also undefined, and r326242 exposed an assertion failure in that case. Just warn on that case instead of crashing, by moving the local binding check before the undefined symbol addition. The input file for the test is crafted by hand, since I don't know of any tool that would produce such a broken DSO. I also don't understand what it even means for a symbol to be undefined but have STB_LOCAL binding - I don't think that combination makes any sense - but we have found broken DSOs of this nature that we were linking against. I've included detailed instructions on how to produce the DSO in the test. Differential Revision: https://reviews.llvm.org/D52815 llvm-svn: 343745
* [ELF] Read the call graph profile from object files.Michael J. Spencer2018-10-021-0/+5
| | | | | | | | | | This uses the call graph profile embedded in the object files to construct the call graph. This is read from a SHT_LLVM_CALL_GRAPH_PROFILE (0x6fff4c02) section as (uint32_t, uint32_t, uint64_t) tuples as (from symbol index, to symbol index, weight). Differential Revision: https://reviews.llvm.org/D45850 llvm-svn: 343552
* Reset input section pointers to null on each linker invocation.Rui Ueyama2018-09-251-3/+3
| | | | | | | | | | 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
* Fix an error message. It must start with a lowercase letter.Rui Ueyama2018-09-251-1/+1
| | | | llvm-svn: 342992
* [PPC64] Handle ppc64le triple in getBitcodeMachineKind.Sean Fertile2018-09-201-0/+1
| | | | | | | | Enables lto and thinlto with bitcode targeting ppc64le. Differential Revision: https://reviews.llvm.org/D52265 llvm-svn: 342604
* [ELF] Check if LinkSec is nullptr when initializing SHF_LINK_ORDER sectionsFangrui Song2018-09-071-2/+4
| | | | | | | | | | | | | | Summary: This protects lld from a null pointer dereference when a faulty input file has such invalid sh_link fields. Reviewers: ruiu, espindola Reviewed By: ruiu Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D51743 llvm-svn: 341611
* Handle identifying AMDGPU bitcode filesMatt Arsenault2018-08-271-0/+3
| | | | llvm-svn: 340738
* [ELF] -thinlto-object-suffix-replace=: don't error if the path does not end ↵Fangrui Song2018-08-211-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with old suffix Summary: For -thinlto-object-suffix-replace=old\;new, in tools/gold/gold-plugin.cpp, the thinlto object filename is Path minus optional old suffix. static std::string getThinLTOObjectFileName(StringRef Path, StringRef OldSuffix, StringRef NewSuffix) { if (OldSuffix.empty() && NewSuffix.empty()) return Path; StringRef NewPath = Path; NewPath.consume_back(OldSuffix); std::string NewNewPath = NewPath; NewNewPath += NewSuffix; return NewNewPath; } Currently lld will error that the path does not end with old suffix. This patch makes lld accept such paths but only add new suffix if Path ends with old suffix. This fixes a link error where bitcode members in an archive are regular LTO objects without old suffix. Acording to tejohnson, this will "enable supporting mix and match of minimized ThinLTO bitcode files with normal ThinLTO bitcode files in a single link (where we want to apply the suffix replacement to the minimized files, and just ignore it for the normal ThinLTO files)." Reviewers: ruiu, pcc, tejohnson, espindola Reviewed By: tejohnson Subscribers: emaste, inglorion, arichardson, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D51055 llvm-svn: 340364
* [LLD][ELF] - Check the architecture of lazy objects earlier.George Rimar2018-08-211-16/+2
| | | | | | | | | | | | | | | | | | | | | | Our code in LazyObjFile::parse() has an ELFT switch and adds a lazy object by its ELFT kind. Though it might be possible to add a file using a different architecture and make LLD to silently accept it (if the file is empty or contains only week symbols). That itself, not a huge issue perhaps (because the error would be reported later if the file is fetched), but still does not look clean and correct. It is possible to report an error earlier and clean up the code. That is what the patch does. Ideally, we might want to reuse isCompatible from SymbolTable.cpp, but it is static and accepts a file as an argument, what is not convenient. Since such a situation should be rare, I think it should be OK to go with the way chosen in this patch. Differential revision: https://reviews.llvm.org/D50899 llvm-svn: 340257
* [LLD][ELF] - Remove dead code. NFC.George Rimar2018-08-171-4/+0
| | | | | | These lines were unused. llvm-svn: 340011
* [LLD][ELF] - Handle SHT_GROUP more carefully. NFCI.George Rimar2018-08-151-1/+5
| | | | | | | | | | | | This patch solves 2 problems: 1) It adds a test to check the line below: https://github.com/llvm-mirror/lld/blob/master/ELF/InputFiles.cpp#L334 Test case contains SHT_GROUP section with a broken (0xFF) flag. 2) The patch fixes the case when we silently accepted such broken groups in the case when there were no other objects with the same group signature. llvm-svn: 339765
* [LLD][ELF] - Remove redundant code. NFC.George Rimar2018-08-021-2/+1
| | | | | | | | Code was never executed with our test cases, though it is valid and I think we can always run it. This improves code coverage. llvm-svn: 338708
* Update for DWARF API changeReid Kleckner2018-08-011-1/+1
| | | | llvm-svn: 338642
* [ELF][ARM] Implement support for Tag_ABI_VFP_argsPeter Smith2018-07-311-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Tag_ABI_VFP_args build attribute controls the procedure call standard used for floating point parameters on ARM. The values are: 0 - Base AAPCS (FP Parameters passed in Core (Integer) registers 1 - VFP AAPCS (FP Parameters passed in FP registers) 2 - Toolchain specific (Neither Base or VFP) 3 - Compatible with all (No use of floating point parameters) If the Tag_ABI_VFP_args build attribute is missing it has an implicit value of 0. We use the attribute in two ways: - Detect a clash in calling convention between Base, VFP and Toolchain. we follow ld.bfd's lead and do not error if there is a clash between an implicit Base AAPCS caused by a missing attribute. Many projects including the hard-float (VFP AAPCS) version of glibc contain assembler files that do not use floating point but do not have Tag_ABI_VFP_args. - Set the EF_ARM_ABI_FLOAT_SOFT or EF_ARM_ABI_FLOAT_HARD ELF header flag for Base or VFP AAPCS respectively. This flag is used by some ELF loaders. References: - Addenda to, and Errata in, the ABI for the ARM Architecture for Tag_ABI_VFP_args - Elf for the ARM Architecture for ELF header flags Fixes PR36009 Differential Revision: https://reviews.llvm.org/D49993 llvm-svn: 338377
* ELF: Implement --icf=safe using address-significance tables.Peter Collingbourne2018-07-181-0/+11
| | | | | | Differential Revision: https://reviews.llvm.org/D48146 llvm-svn: 337429
* Implement framework for linking split-stack object files, and x86_64 support.Sterling Augustine2018-07-171-6/+17
| | | | llvm-svn: 337332
* [ELF] - Eliminate ObjFile<ELFT>::getLineInfo. NFC.George Rimar2018-07-161-8/+0
| | | | | | Flow is the same, but a bit shorter after this change. llvm-svn: 337183
* Remove a dead variable.Rui Ueyama2018-06-091-1/+0
| | | | llvm-svn: 334341
* Correct aligment computation for shared object symbols.Han Shen2018-06-061-6/+2
| | | | | | | | | | The original computation for shared object symbol alignment is wrong when st_value equals 0. It is very unusual for dso symbols to have st_value equal 0. But when it happens, it causes obscure run time bugs. Differential Revision: https://reviews.llvm.org/D47602 llvm-svn: 334135
* [ELF] - Also use DW_AT_linkage_name when gathering information about ↵George Rimar2018-06-041-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | variables for error messages. Currently, when LLD do a lookup for variables location, it uses DW_AT_name attribute. That is not always enough. Imagine code: namespace A { int bar = 0; } namespace Z { int bar = 1; } int hoho; In this case there are 3 variables and their debug attributes are following: A::bar has: DW_AT_name [DW_FORM_string] ("bar") DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x00000006] = "_ZN1A3barE") Z::bar has: DW_AT_name [DW_FORM_string] ("bar") DW_AT_linkage_name [DW_FORM_strp] ( .debug_str[0x0000003f] = "_ZN1Z3barE") hoho has: DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000004a] = "hoho") and has NO DW_AT_linkage_name attribute. Because it would be the same as DW_AT_name and DWARF producers avoids emiting excessive data. Hence LLD should also use DW_AT_linkage_name when it is available. (currently, LLD fails to report location correctly because thinks that A::bar and Z::bar are the same things) Differential revision: https://reviews.llvm.org/D47373 llvm-svn: 333880
* Code cleanup in preparation for adding LTO for wasm. NFC.Sam Clegg2018-05-221-7/+8
| | | | | | | | | | | | | | - Move some common code into Common/rrorHandler.cpp and Common/Strings.h. - Don't use `fatal` when incompatible bitcode files are encountered. - Rename NameRef variable to just Name See D47162 Differential Revision: https://reviews.llvm.org/D47206 llvm-svn: 333021
* [ELF] Update due to API change in .debug_line parsingJames Henderson2018-05-211-3/+6
| | | | | | | | | | See r332845. Reviewed by: grimar Differential Revision: https://reviews.llvm.org/D46832 llvm-svn: 332846
* Fix typo in error message.Rui Ueyama2018-05-171-1/+1
| | | | llvm-svn: 332658
* Improve error message for -thinlto-object-suffix-replace and simplify code.Rui Ueyama2018-05-171-10/+21
| | | | llvm-svn: 332643
OpenPOWER on IntegriCloud