summaryrefslogtreecommitdiffstats
path: root/lld
Commit message (Collapse)AuthorAgeFilesLines
...
* [WebAssembly] Add --reproduce.Rui Ueyama2019-05-215-0/+87
| | | | | | | | | | | | | | | --reproduce is a convenient option for debugging. If you invoke lld with `--reproduce=repro.tar`, it creates `repro.tar` with all input files and the command line options given to the linker, so that it is very easy to run lld with the exact same inputs. ELF and Windows lld have this option. This patch add that option to lld/wasm. Differential Revision: https://reviews.llvm.org/D62170 llvm-svn: 361244
* [WebAssembly] Add __start_/_stop_ symbols for data sectionsSam Clegg2019-05-215-10/+113
| | | | | | | | Fixes https://bugs.llvm.org/show_bug.cgi?id=41565 Differential Revision: https://reviews.llvm.org/D61876 llvm-svn: 361236
* [WebAssembly] Refactor synthetic sections and relocation processing. NFC.Sam Clegg2019-05-2113-931/+1186
| | | | | | | | | | | Major refactor to better match the structure of the ELF linker. - Split out relocation processing into scanRelocations - Split out synthetic sections into their own classes. Differential Revision: https://reviews.llvm.org/D61811 llvm-svn: 361233
* [ELF] Don't advance position in a memory region when assigning to the DotFangrui Song2019-05-212-4/+2
| | | | | | | | | | | | | For memory5.test, ld.bfd appears to ignore `. += 0x2000;`, so the test was testing a wrong behavior. After deleting the code added in rLLD336335, we match ld.bfd and thus fix PR41357. PR37836 (memory4.test) seems to have been fixed by another change. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62177 llvm-svn: 361228
* [ELF] Error on relocations to local undefined symbolsFangrui Song2019-05-212-11/+11
| | | | | | | | | | | | | | | | For a reference to a local symbol, ld.bfd and gold error if the symbol is defined in a discarded section but accept it if the symbol is undefined. This inconsistent behavior seems unnecessary for us (it probably makes sense for them as they differentiate local/global symbols, the error would mean more code). Catch such errors. Symbol index 0 may be used by marker relocations, e.g. R_*_NONE R_ARM_V4BX. Don't error on them. The difference from D61563 (which caused msan failure) is we don't call Sym.computeBinding() on local symbols - VersionId is uninitialized. llvm-svn: 361213
* Revert r361206 "[COFF] Store alignment in log2 form, NFC"Nico Weber2019-05-217-53/+30
| | | | | | Makes the linker crash when linking nasm.exe. llvm-svn: 361212
* [COFF] Store alignment in log2 form, NFCReid Kleckner2019-05-207-30/+53
| | | | | | | | | | | | | | | | | Summary: Valid section or chunk alignments are powers of 2 in the range [1, 8192]. These can be stored more canonically in log2 form to free up some bits in Chunk. Combined with D61696, SectionChunk gets 8 bytes smaller. Reviewers: ruiu, aganea Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61698 llvm-svn: 361206
* [ELF][Driver] Fix precedence of symbol ordering file and CGProfileTiancong Wang2019-05-202-3/+76
| | | | | | | | | This patch is a fix for https://bugs.llvm.org/show_bug.cgi?id=41804. We try to solve the precedence of user-specified symbol ordering file and C3 ordering provided as call graph. It deals with two case: (1) When both --symbol-ordering-file=<file> and --call-graph-order-file=<file> are present, whichever flag comes later will take precedence. (2) When only --symbol-ordering-file=<file> is present, it takes precedence over implicit call graph (CGProfile) generated by CGProfilePass enabled in new pass manager. llvm-svn: 361190
* Test commit, add an empty line.Tiancong Wang2019-05-201-0/+1
| | | | llvm-svn: 361186
* [ELF] -z combreloc: sort dynamic relocations by ↵Fangrui Song2019-05-204-105/+58
| | | | | | | | | | | | | | | | | | | | | | (!is_relative,symbol_index,r_offset) We currently sort dynamic relocations by (!is_relative,symbol_index). Add r_offset as the third key. This makes `readelf -r` debugging easier (relocations to the same symbol are ordered by r_offset). Refactor the test combreloc.s (renamed from combrelocs.s) to check R_X86_64_RELATIVE, and delete --expand-relocs. The difference from the reverted D61477 is that we keep !is_relative as the first key. In local dynamic TLS model, DTPMOD (e.g. R_ARM_TLS_DTPMOD32 R_X86_64_DTPMOD and R_PPC{,64}_DTPMOD) may use 0 as the symbol index. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D62141 llvm-svn: 361164
* Revert "[ELF] Error on relocations to local undefined symbols"Dmitri Gribenko2019-05-202-9/+9
| | | | | | | | This reverts commit r361144. It causes a use-of-uninitialized-value in maybeReportUndefined at llvm/tools/lld/ELF/Relocations.cpp:682, as detected by MemorySanitizer when local-undefined-symbol.s test is run. llvm-svn: 361162
* Revert "[ELF] -z combreloc: sort dynamic relocations by (symbol_index,r_offset)"Dmitri Gribenko2019-05-205-58/+107
| | | | | | | | This reverts commit r361125. This linker change breaks shared libraries in some subtle way on x86_64. (Specifically, gold segfaults when loading the LLVMgold.so plugin linked with lldb with this patch.) llvm-svn: 361150
* [ELF] Fix getRelocTargetVA formulae of R_TLS and R_NEG_TLSFangrui Song2019-05-203-8/+40
| | | | | | | | | | | | | | | | | | | | | | For R_TLS: 1) Delete Sym.isTls() . The assembler ensures the symbol is STT_TLS. If not (the input is broken), we would crash (dereferencing null Out::TlsPhdr). 2) Change Sym.isUndefWeak() to Sym.isUndefined(), otherwise with --noinhibit-exec we would still evaluate the symbol and crash. 3) Return A if the symbol is undefined. This is PR40570. The case is probably unrealistic but returning A matches R_ABS and the behavior of several dynamic loaders. R_NEG_TLS is obsoleted Sun TLS we don't fully support, but R_RELAX_TLS_GD_TO_LE_NEG is still used by GD->LE relaxation (subl $var@tpoff,%eax). They should add the addend. Unfortunately I can't test it as compilers don't seem to generate non-zero implicit addends. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62098 llvm-svn: 361146
* [ELF] Error on relocations to local undefined symbolsFangrui Song2019-05-202-9/+9
| | | | | | | | | | | | | | | | | For a reference to a local symbol, ld.bfd and gold error if the symbol is defined in a discarded section but accept it if the symbol is undefined. This inconsistent behavior seems unnecessary for us (it probably makes sense for them as they differentiate local/global symbols, the error would mean more code). Weaken the condition to getSymbol(Config->IsMips64EL) == 0 to catch such errors. The symbol index can be 0 (e.g. R_*_NONE R_ARM_V4BX) and we shouldn't error on them. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D61563 llvm-svn: 361144
* [MIPS] Update mips-abs-got.s to not use .relocFangrui Song2019-05-201-3/+3
| | | | | | As Simon Atanasyan suggested in D61563 llvm-svn: 361142
* [ELF] Fix tests from r361013 on ARM/AARch64 bots.Yvan Roux2019-05-202-0/+4
| | | | llvm-svn: 361128
* [ELF] -z combreloc: sort dynamic relocations by (symbol_index,r_offset)Fangrui Song2019-05-205-107/+58
| | | | | | | | | | | | | | | | | | | | | | Fixes PR41692. We currently sort dynamic relocations by (!is_relative,symbol_index). Change it to (symbol_index,r_offset). We still place relative relocations first because R_*_RELATIVE are the only dynamic relocations with 0 symbol index (except on MIPS, which doesn't use DT_REL[A]COUNT anyway). This makes `readelf -r` debugging easier (relocations to the same symbol are ordered by r_offset). Refactor the test combreloc.s (renamed from combrelocs.s) to check R_X86_64_RELATIVE, and delete --expand-relocs. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D61477 llvm-svn: 361125
* Make replaceSymbol a member function of Symbol.Rui Ueyama2019-05-206-46/+50
| | | | | | | | | | | | This is a mechanical rewrite of replaceSymbol(A, B) to A->replace(B). I also added a comment to Symbol::replace(). Technically this change is not necessary, but this change makes code a bit more concise. Differential Revision: https://reviews.llvm.org/D62117 llvm-svn: 361123
* [ELF] Copy IsPreemptible in replaceSymbol()Fangrui Song2019-05-202-0/+15
| | | | | | | | | | | Otherwise, we may set IsPreemptible (e.g. --dynamic-list) then clear it (in replaceCommonSymbols()). Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62107 llvm-svn: 361122
* Suppress false-positive GCC -Wreturn-type warning.Michael Liao2019-05-181-0/+1
| | | | llvm-svn: 361094
* [MinGW] Set the right updated option help for the updated pdb option. NFCMartin Storsjo2019-05-181-2/+1
| | | | | | | I forgot to amend this change before committing it in SVN r361014, this is what was agreed upon in the review. llvm-svn: 361093
* [ARM][AArch64] Revert Android Bionic PT_TLS overaligning hackFangrui Song2019-05-189-61/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts D53906. D53906 increased p_align of PT_TLS on ARM/AArch64 to 32/64 to make the static TLS layout compatible with Android Bionic's ELF TLS. However, this may cause glibc ARM/AArch64 programs to crash (see PR41527). The faulty PT_TLS in the executable satisfies p_vaddr%p_align != 0. The remainder is normally 0 but may be non-zero with the hack in place. The problem is that we increase PT_TLS's p_align after OutputSections' addresses are fixed (assignAddress()). It is possible that p_vaddr%old_p_align = 0 while p_vaddr%new_p_align != 0. For a thread local variable defined in the executable, lld computed TLS offset (local exec) is different from glibc computed TLS offset from another module (initial exec/generic dynamic). Note: PR41527 said the bug affects initial exec but actually generic dynamic is affected as well. (glibc is correct in that it compute offsets that satisfy `offset%p_align == p_vaddr%p_align`, which is a basic ELF requirement. This hack appears to work on FreeBSD rtld, musl<=1.1.22, and Bionic, but that is just because they (and lld) incorrectly compute offsets that satisfy `offset%p_align = 0` instead.) Android developers are fine to revert this patch, carry this patch in their tree before figuring out a long-term solution (e.g. a dummy .tdata with sh_addralign=64 sh_size={0,1} in crtbegin*.o files. The overhead is now insignificant after D62059). Reviewed By: rprichard, srhines Differential Revision: https://reviews.llvm.org/D62055 llvm-svn: 361090
* [ELF][X86] Fix R_RELAX_TLS_GD_TO_LE_NEG and R_NEG_TLS after D62059Fangrui Song2019-05-182-3/+16
| | | | | | | | | | | | | After D62059, we don't align p_memsz of PT_TLS to p_align. The getRelocTargetVA formula should align it instead. It becomes clear that R_NEG_TLS and R_TLS are opposite from each other. In i386-tls-le-align.s, I put ret after call ___tls_get_addr@plt as otherwise ld.bfd would reject the relaxation: TLS transition from R_386_TLS_GD to R_386_TLS_LE_32 against `a' at 0x3 in section `.text' failed llvm-svn: 361088
* [ELF] Add {i386,x86-64}-tls-le-align.s to test TP offsets for TLS Variant 2Fangrui Song2019-05-182-0/+32
| | | | | | I forgot to add them in rLLD361084. I made another mistake, rLLD361084 fixed Variant 2, not Variant 1. llvm-svn: 361085
* [ELF] Fix TP offset of TLS Variant I after D62059Fangrui Song2019-05-181-1/+1
| | | | | | | | | | | As Ryan Prichard pointed out, after D62059, the TP offset is incorrect. Add x86-64-tls-le-align.s to check this. Better formulae for both variants should take p_vaddr%p_align into account (offset%p_align = p_vaddr%p_align is a basic ELF requirement), but I can't find a way to test the behavior. llvm-svn: 361084
* Fix tests from r361013 on X86 bots.Russell Gallop2019-05-172-0/+4
| | | | llvm-svn: 361041
* [ELF] -r: fix R_*_NONE to section symbols on Elf*_Rel targetsFangrui Song2019-05-173-1/+15
| | | | | | | | | | | | | | | | | On Elf*_Rel targets, for a relocation to a section symbol, an R_ABS is added which will be used by relocateOne() to compute the implicit addend. Addends of R_*_NONE should be ignored, so don't emit an R_ABS. This fixes crashes on X86 and ARM because their relocateOne() do not handle R_*_NONE. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D62052 llvm-svn: 361036
* [ELF] Don't align PT_TLS's p_memszFangrui Song2019-05-172-26/+0
| | | | | | | | | | | | | | | The code was added in r252352, probably to address some layout issues. Actually PT_TLS's p_memsz doesn't need to be aligned on either variant. ld.bfd doesn't do that. In case of larger alignment (e.g. 64 for Android Bionic on AArch64, see D62055), this may make the overhead smaller. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62059 llvm-svn: 361029
* [MinGW] Include --enable-auto-import in the help listingMartin Storsjo2019-05-172-1/+5
| | | | | | | | | Libtool concludes that the linker doesn't support shared libraries, unless this flag is listed in the output of --help. Differential Revision: https://reviews.llvm.org/D62053 llvm-svn: 361017
* [MinGW] Implement the -v and --version flags for the MinGW driverMartin Storsjo2019-05-173-2/+23
| | | | | | Differential Revision: https://reviews.llvm.org/D62030 llvm-svn: 361016
* [MinGW] Implement --help for the MinGW driverMartin Storsjo2019-05-172-2/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D62029 llvm-svn: 361015
* [MinGW] Allow requesting PDB output without giving a file nameMartin Storsjo2019-05-173-2/+11
| | | | | | | | | | | | | | | | | | | | | When integrating PDB output in mingw targeting build systems, it might be a lot of extra work to specify unique file names for the pdb output. Therefore allow omitting the actual file name and let it implicitly be the same name as the linker output, with a pdb extension. As the current form of the pdb option takes a separate parameter value, e.g. "-pdb out.pdb", it is impractical to leave out the parameter value. Therefore, introduce a second syntax for the option, with an equals sign, like -pdb=out.pdb, where the value easily can be omitted. The form -pdb= for requesting pdb files with an implicit name should work fine, even though it looks a bit unconventional in that form. Differential Revision: https://reviews.llvm.org/D62004 llvm-svn: 361014
* [ELF][test] Reorganize some R_*_NONE testsFangrui Song2019-05-1711-114/+99
| | | | | | | | | | | | | | | Change R_{386,AARCH64}_NONE yaml2obj tests/icf10.test to use assembly Add relocation-none-{arm,x86_64}.s. Check the referenced section survives under --gc-sections. Check -r copies R_X86_64_NONE R_AARCH64_NONE. (Elf*_Rel arches currently have a bug) Delete the dtrace tests as they are covered by the R_X86_64_NONE test. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D62051 llvm-svn: 361013
* [ELF] Implement Dependent Libraries FeatureBen Dunbobbin2019-05-1712-8/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-179-182/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r358069 "Discard debuginfo for object files empty after GC"Bob Haarman2019-05-167-56/+19
| | | | | | | | 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
* [WebAssembly] Move code and data section generation to finalizeContent. NFC.Sam Clegg2019-05-163-21/+41
| | | | | | | | | | | | | | Previously these sections were being generated during their constructors. This moves the work to finalizeContent, and also does the same for the relocation sections because their contents depends on the final layout too. This change is part of a larger refactor to how we deal with synthetic sections: https://reviews.llvm.org/D61811 Differential Revision: https://reviews.llvm.org/D61971 llvm-svn: 360941
* [WebAssembly] Don't generate empty type sections.Sam Clegg2019-05-162-0/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D61991 llvm-svn: 360940
* [lld-link] Add missing "REQUIRES: x86" to COFF/lib-module-asm.ll test.Yvan Roux2019-05-161-0/+1
| | | | | | This should fix ARM bots. llvm-svn: 360875
* Add missing "REQUIRES: x86" to the lto/irmover-warning.ll test.Igor Kudrin2019-05-161-0/+1
| | | | llvm-svn: 360866
* [LTO] Improve readability of module IDsIgor Kudrin2019-05-163-4/+37
| | | | | | | | | 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-163-19/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D61897 llvm-svn: 360846
* Consistently return `Symbol *` from SymbolTable's add-family functions.Rui Ueyama2019-05-162-12/+18
| | | | llvm-svn: 360845
* De-template parseFile() and SymbolTable's add-family functions.Rui Ueyama2019-05-165-75/+55
| | | | | | Differential Revision: https://reviews.llvm.org/D61896 llvm-svn: 360844
* Introduce CommonSymbol.Rui Ueyama2019-05-168-124/+183
| | | | | | | | | | | | | | | | | 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-1610-352/+332
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Fix typo in header guard. NFC.Sam Clegg2019-05-161-2/+2
| | | | llvm-svn: 360832
* [lld] Remove 2>&1 from --trace-symbol testsSam Clegg2019-05-152-13/+13
| | | | | | | | | | | | | The tracing goes to stdout so this is not needed. Also remove the "not" from the final check in ELF/trace-symbols.s. According the comment the check is that we don't crash, so we should be checking for success here. Previously this step is error'ing with undefined symbols because it didn't include all the needed objects. Differential Revision: https://reviews.llvm.org/D61928 llvm-svn: 360794
* [WebAssembly] LTO: Honor comdat groups when loading bitcode filesSam Clegg2019-05-155-19/+49
| | | | | | | | | But don't apply comdat groups when loading the LTO object files. This is basically the same logic used by the ELF linker. Differential Revision: https://reviews.llvm.org/D61924 llvm-svn: 360782
* [LLD][ELF] Add the -z ifunc-noplt optionFangrui Song2019-05-147-3/+166
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Mark Johnston! Summary: When the option is configured, ifunc calls do not go through the PLT; rather, they appear as regular function calls with relocations referencing the ifunc symbol, and the resolver is invoked when applying the relocation. This is intended for use in freestanding environments where text relocations are permissible and is incompatible with the -z text option. The option is motivated by ifunc usage in the FreeBSD kernel, where ifuncs are used to elide CPU feature flag bit checks in hot paths. Instead of replacing the cost of a branch with that of an indirect function call, the -z ifunc-noplt option is used to ensure that ifunc calls carry no hidden overhead relative to normal function calls. Test Plan: I added a couple of regression tests and tested the FreeBSD kernel build using the latest lld sources. To demonstrate the effects of the change, I used a micro-benchmark which results in frequent invocations of a FreeBSD kernel ifunc. The benchmark was run with and without IBRS enabled, and with and without -zifunc-noplt configured. The observed speedup is small and consistent, and is significantly larger with IBRS enabled: https://people.freebsd.org/~markj/ifunc-noplt/noibrs.txt https://people.freebsd.org/~markj/ifunc-noplt/ibrs.txt Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D61613 llvm-svn: 360685
OpenPOWER on IntegriCloud