summaryrefslogtreecommitdiffstats
path: root/lld/ELF/InputFiles.h
Commit message (Collapse)AuthorAgeFilesLines
* Forward declare the DWARFCache to avoid including LLVM DWARF detailsReid Kleckner2019-11-141-1/+2
| | | | | 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.
* [LLD] Move duplicated dwarf parsing code to the Common library. NFC.Martin Storsjo2019-10-211-10/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D69197 llvm-svn: 375390
* Improve error message for bad SHF_MERGE sectionsRui Ueyama2019-10-101-1/+1
| | | | | | | | 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-4/+2
| | | | | | | | | | | 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] Fix variable names in comments after VariableName -> variableName changeFangrui Song2019-07-161-2/+2
| | | | | | Also fix some typos. llvm-svn: 366181
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-101-116/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PPC32] Improve the 32-bit PowerPC portFangrui Song2019-06-061-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many -static/-no-pie/-shared/-pie applications linked against glibc or musl should work with this patch. This also helps FreeBSD PowerPC64 to migrate their lib32 (PR40888). * Fix default image base and max page size. * Support new-style Secure PLT (see below). Old-style BSS PLT is not implemented, so it is not suitable for FreeBSD rtld now because it doesn't support Secure PLT yet. * Support more initial relocation types: R_PPC_ADDR32, R_PPC_REL16*, R_PPC_LOCAL24PC, R_PPC_PLTREL24, and R_PPC_GOT16. The addend of R_PPC_PLTREL24 is special: it decides the call stub PLT type but it should be ignored for the computation of target symbol VA. * Support GNU ifunc * Support .glink used for lazy PLT resolution in glibc * Add a new thunk type: PPC32PltCallStub that is similar to PPC64PltCallStub. It is used by R_PPC_REL24 and R_PPC_PLTREL24. A PLT stub used in -fPIE/-fPIC usually loads an address relative to .got2+0x8000 (-fpie/-fpic code uses _GLOBAL_OFFSET_TABLE_ relative addresses). Two .got2 sections in two object files have different addresses, thus a PLT stub can't be shared by two object files. To handle this incompatibility, change the parameters of Thunk::isCompatibleWith to `const InputSection &, const Relocation &`. PowerPC psABI specified an old-style .plt (BSS PLT) that is both writable and executable. Linkers don't make separate RW- and RWE segments, which causes all initially writable memory (think .data) executable. This is a big security concern so a new PLT scheme (secure PLT) was developed to address the security issue. TLS will be implemented in D62940. glibc older than ~2012 requires .rela.dyn to include .rela.plt, it can not handle the DT_RELA+DT_RELASZ == DT_JMPREL case correctly. A hack (not included in this patch) in LinkerScript.cpp addOrphanSections() to work around the issue: if (Config->EMachine == EM_PPC) { // Older glibc assumes .rela.dyn includes .rela.plt Add(In.RelaDyn); if (In.RelaPlt->isLive() && !In.RelaPlt->Parent) In.RelaDyn->getParent()->addSection(In.RelaPlt); } Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62464 llvm-svn: 362721
* [lld] Explicitly ignore comdat groups when parsing LTO object(s)Sam Clegg2019-06-051-7/+3
| | | | | | | | | | | | | 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
* Read .note.gnu.property sections and emit a merged .note.gnu.property section.Rui Ueyama2019-06-051-0/+2
| | | | | | | | | | | | | 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
* Merge ELFFileBase::{initSymtab,parseHeader} as ELFFileBase:init. NFC.Rui Ueyama2019-05-281-7/+11
| | | | | | | | 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-1/+0
| | | | llvm-svn: 361747
* [WebAssebmly] Add support for --wrapSam Clegg2019-05-241-1/+1
| | | | | | | | | | | The code for implementing this features is taken almost verbatim from the ELF backend. Fixes: https://bugs.llvm.org/show_bug.cgi?id=41681 Differential Revision: https://reviews.llvm.org/D62380 llvm-svn: 361639
* Simplify InputFile::fetch().Rui Ueyama2019-05-231-3/+3
| | | | | | | 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-2/+0
| | | | | | | Instead we can just clear a MemoryBuffer so that we cannot get the same buffer more than once. llvm-svn: 361477
* Speed up --start-lib and --end-lib.Rui Ueyama2019-05-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --{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-7/+9
| | | | | | | | | | | | | | | | | | | | | 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
* Revert r358069 "Discard debuginfo for object files empty after GC"Bob Haarman2019-05-161-4/+0
| | | | | | | | The change broke some scenarios where debug information is still needed, although MarkLive cannot see it, including the Chromium/Android build. Reverting to unbreak that build. llvm-svn: 360955
* De-template parseFile() and SymbolTable's add-family functions.Rui Ueyama2019-05-161-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D61896 llvm-svn: 360844
* Move SymbolTable::addFile to InputFiles.cpp.Rui Ueyama2019-05-141-0/+3
| | | | | | | | | | | | | | | | | 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
* [ELF] Fix typo: .symtab_shndxr -> .symtab_shndxFangrui Song2019-04-121-3/+3
| | | | | | | | The typo was introduced to llvm MC in rL204769 (fixed in rL358247) and then to lld. Also, for relocatable-many-sections.s, the size of .symtab changed at some point and the formula needs update. llvm-svn: 358248
* Discard debuginfo for object files empty after GCRui Ueyama2019-04-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | Patch by Robert O'Callahan. Rust projects tend to link in all object files from all dependent libraries and rely on --gc-sections to strip unused code and data. Unfortunately --gc-sections doesn't currently strip any debuginfo associated with GC'ed sections, so lld links in the full debuginfo from all dependencies even if almost all that code has been discarded. See https://github.com/rust-lang/rust/issues/56068 for some details. Properly stripping debuginfo for discarded sections would be difficult, but a simple approach that helps significantly is to mark debuginfo sections as live only if their associated object file has at least one live code/data section. This patch does that. In a (contrived but not totally artificial) Rust testcase linked above, it reduces the final binary size from 46MB to 5.1MB. Differential Revision: https://reviews.llvm.org/D54747 llvm-svn: 358069
* Rename a variable and add a comment.Rui Ueyama2019-04-101-1/+13
| | | | llvm-svn: 358049
* ELF: Move verneed tracking data structures out of VersionNeedSection.Peter Collingbourne2019-04-081-12/+8
| | | | | | | | | | | | | | | | 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-19/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D60305 llvm-svn: 357925
* ELF: De-template ELFFileBase. NFCI.Peter Collingbourne2019-04-051-19/+23
| | | | | | Differential Revision: https://reviews.llvm.org/D60304 llvm-svn: 357806
* ELF: Move SymtabSHNDX and getSectionIndex() to ObjFile. NFCI.Peter Collingbourne2019-04-041-3/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D60244 llvm-svn: 357670
* Replace `typedef A B` with `using B = A`. NFC.Rui Ueyama2019-04-011-18/+18
| | | | | | | | I did this using Perl. Differential Revision: https://reviews.llvm.org/D60003 llvm-svn: 357372
* 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
* [PPC64] Sort .toc sections accessed with small code model relocs.Sean Fertile2019-02-121-8/+9
| | | | | | | | | | | | | A follow up to the intial patch that unblocked linking against libgcc. For lld we don't need to bother tracking which objects have got based small code model relocations. This is due to the fact that the compilers on powerpc64 use the .toc section to generate indirections to symbols (rather then using got relocations) which keeps the got small. This makes overflowing a small code model got relocation very unlikely. Differential Revision: https://reviews.llvm.org/D57245 llvm-svn: 353849
* [ELF] Support --{,no-}allow-shlib-undefinedFangrui Song2019-02-011-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove dead declaration.Rui Ueyama2019-01-261-1/+0
| | | | llvm-svn: 352257
* [PPC64] Reland r351978 'Sort .toc sections accessed with small code model ...'Sean Fertile2019-01-241-0/+10
| | | | | | | | | | | | | | | | | | | | | | | Guessing that the slashes used in the scripts SECTION command was causing the windows related failures in the added test. Original commit message: Small code model global variable access on PPC64 has a very limited range of addressing. The instructions the relocations are used on add an offset in the range [-0x8000, 0x7FFC] to the toc pointer which points to .got +0x8000, giving an addressable range of [.got, .got + 0xFFFC]. While user code can be recompiled with medium and large code models when the binary grows too large for small code model, there are small code model relocations in the crt files and libgcc.a which are typically shipped with the distros, and the ABI dictates that linkers must allow linking of relocatable object files using different code models. To minimze the chance of relocation overflow, any file that contains a small code model relocation should have its .toc section placed closer to the .got then any .toc from a file without small code model relocations. Differential Revision: https://reviews.llvm.org/D56920 llvm-svn: 352071
* Revert "[PPC64] Sort .toc sections accessed with small code model ..."Sean Fertile2019-01-231-10/+0
| | | | | | | This reverts commit ca87c57a3aa4770c9cf0defd4b2feccbc342ee93. Added test fails on several windows buildbots. llvm-svn: 351985
* [PPC64] Sort .toc sections accessed with small code model relocs close to .got.Sean Fertile2019-01-231-0/+10
| | | | | | | | | | | | | | | | | | | Small code model global variable access on PPC64 has a very limited range of addressing. The instructions the relocations are used on add an offset in the range [-0x8000, 0x7FFC] to the toc pointer which points to .got +0x8000, giving an addressable range of [.got, .got + 0xFFFC]. While user code can be recompiled with medium and large code models when the binary grows too large for small code model, there are small code model relocations in the crt files and libgcc.a which are typically shipped with the distros, and the ABI dictates that linkers must allow linking of relocatable object files using different code models. To minimze the chance of relocation overflow, any file that contains a small code model relocation should have its .toc section placed closer to the .got then any .toc from a file without small code model relocations. Differential Revision: https://reviews.llvm.org/D56920 llvm-svn: 351978
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Use unique_ptr to manage a TarWriter instance. NFC.Rui Ueyama2018-12-181-1/+1
| | | | llvm-svn: 349581
* [ELF] Read the call graph profile from object files.Michael J. Spencer2018-10-021-0/+4
| | | | | | | | | | 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
* Change how we handle -wrap.Rui Ueyama2018-08-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have an issue with -wrap that the option doesn't work well when renamed symbols get PLT entries. I'll explain what is the issue and how this patch solves it. For one -wrap option, we have three symbols: foo, wrap_foo and real_foo. Currently, we use memcpy to overwrite wrapped symbols so that they get the same contents. This works in most cases but doesn't when the relocation processor sets some flags in the symbol. memcpy'ed symbols are just aliases, so they always have to have the same contents, but the relocation processor breaks that assumption. r336609 is an attempt to fix the issue by memcpy'ing again after processing relocations, so that symbols that are out of sync get the same contents again. That works in most cases as well, but it breaks ASan build in a mysterious way. We could probably fix the issue by choosing symbol attributes that need to be copied after they are updated. But it feels too complicated to me. So, in this patch, I fixed it once and for all. With this patch, we no longer memcpy symbols. All references to renamed symbols point to new symbols after wrapSymbols() is done. Differential Revision: https://reviews.llvm.org/D50569 llvm-svn: 340387
* [LLD][ELF] - Check the architecture of lazy objects earlier.George Rimar2018-08-211-2/+0
| | | | | | | | | | | | | | | | | | | | | | 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
* ELF: Implement --icf=safe using address-significance tables.Peter Collingbourne2018-07-181-0/+3
| | | | | | 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-0/+8
| | | | llvm-svn: 337332
* [ELF] - Eliminate ObjFile<ELFT>::getLineInfo. NFC.George Rimar2018-07-161-3/+0
| | | | | | Flow is the same, but a bit shorter after this change. llvm-svn: 337183
* [ELF][MIPS] Multi-GOT implementationSimon Atanasyan2018-06-111-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Almost all entries inside MIPS GOT are referenced by signed 16-bit index. Zero entry lies approximately in the middle of the GOT. So the total number of GOT entries cannot exceed ~16384 for 32-bit architecture and ~8192 for 64-bit architecture. This limitation makes impossible to link rather large application like for example LLVM+Clang. There are two workaround for this problem. The first one is using the -mxgot compiler's flag. It enables using a 32-bit index to access GOT entries. But each access requires two assembly instructions two load GOT entry index to a register. Another workaround is multi-GOT. This patch implements it. Here is a brief description of multi-GOT for detailed one see the following link https://dmz-portal.mips.com/wiki/MIPS_Multi_GOT. If the sum of local, global and tls entries is less than 64K only single got is enough. Otherwise, multi-got is created. Series of primary and multiple secondary GOTs have the following layout: ``` - Primary GOT Header Local entries Global entries Relocation only entries TLS entries - Secondary GOT Local entries Global entries TLS entries ... ``` All GOT entries required by relocations from a single input file entirely belong to either primary or one of secondary GOTs. To reference GOT entries each GOT has its own _gp value points to the "middle" of the GOT. In the code this value loaded to the register which is used for GOT access. MIPS 32 function's prologue: ``` lui v0,0x0 0: R_MIPS_HI16 _gp_disp addiu v0,v0,0 4: R_MIPS_LO16 _gp_disp ``` MIPS 64 function's prologue: ``` lui at,0x0 14: R_MIPS_GPREL16 main ``` Dynamic linker does not know anything about secondary GOTs and cannot use a regular MIPS mechanism for GOT entries initialization. So we have to use an approach accepted by other architectures and create dynamic relocations R_MIPS_REL32 to initialize global entries (and local in case of PIC code) in secondary GOTs. But ironically MIPS dynamic linker requires GOT entries and correspondingly ordered dynamic symbol table entries to deal with dynamic relocations. To handle this problem relocation-only section in the primary GOT contains entries for all symbols referenced in global parts of secondary GOTs. Although the sum of local and normal global entries of the primary got should be less than 64K, the size of the primary got (including relocation-only entries can be greater than 64K, because parts of the primary got that overflow the 64K limit are used only by the dynamic linker at dynamic link-time and not by 16-bit gp-relative addressing at run-time. The patch affects common LLD code in the following places: - Added new hidden -mips-got-size flag. This flag required to set low maximum size of a single GOT to be able to test the implementation using small test cases. - Added InputFile argument to the getRelocTargetVA function. The same symbol referenced by GOT relocation from different input file might be allocated in different GOT. So result of relocation depends on the file. - Added new ctor to the DynamicReloc class. This constructor records settings of dynamic relocation which used to adjust address of 64kb page lies inside a specific output section. With the patch LLD is able to link all LLVM+Clang+LLD applications and libraries for MIPS 32/64 targets. Differential revision: https://reviews.llvm.org/D31528 llvm-svn: 334390
* Fix build broken by r334341.Rui Ueyama2018-06-091-1/+1
| | | | llvm-svn: 334342
* Remove a dead variable.Rui Ueyama2018-06-091-1/+0
| | | | llvm-svn: 334341
* Improve error message for -thinlto-object-suffix-replace and simplify code.Rui Ueyama2018-05-171-13/+1
| | | | llvm-svn: 332643
* Add support for ThinLTO plugin option thinlto-object-suffix-replaceRumeet Dhindsa2018-05-161-0/+14
| | | | | | Differential Revision: https://reviews.llvm.org/D46608 llvm-svn: 332527
* Added support for ThinLTO plugin options : thinlto-index-only and ↵Rumeet Dhindsa2018-05-021-1/+6
| | | | | | | | thinlto-prefix-replace Differential Revision: https://reviews.llvm.org/D46034 llvm-svn: 331405
* [ELF] --warn-backrefs: use the same GroupId for object files in the same ↵Fangrui Song2018-04-201-3/+3
| | | | | | | | | | | | --{start,end}-lib Reviewers: ruiu, espindola Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D45849 llvm-svn: 330443
* [ELF] Increase NextGroupId with --end-groupFangrui Song2018-04-191-2/+1
| | | | | | | | | | Reviewers: ruiu, espindola Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D45846 llvm-svn: 330379
OpenPOWER on IntegriCloud