summaryrefslogtreecommitdiffstats
path: root/lld/test
Commit message (Collapse)AuthorAgeFilesLines
...
* [ELF] Suggest extern "C" when the definition is mangled while an undefined ↵Fangrui Song2019-11-081-0/+21
| | | | | | | | | | | | | | | | | | | | reference is not The definition may be mangled while an undefined reference is not. This may come up when (1) the reference is from a C file or (2) the definition misses an extern "C". (2) is more common. Suggest an arbitrary mangled name that matches the undefined reference, if such a definition exists. ld.lld: error: undefined symbol: foo >>> referenced by a.o:(.text+0x1) >>> did you mean to declare foo(int) as extern "C"? >>> defined in: a1.o Reviewed By: dblaikie, ruiu Differential Revision: https://reviews.llvm.org/D69650
* [ELF] Suggest extern "C" when an undefined reference is mangled while the ↵Fangrui Song2019-11-081-0/+19
| | | | | | | | | | | | definition is not When missing an extern "C" declaration, an undefined reference may be mangled while the definition is not. Suggest the missing extern "C" and the base name. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D69592
* Keep symbols passed by -init and -finiRui Ueyama2019-11-081-0/+38
| | | | | | | | | | Previously, symbols passed by -init and -fini look as if they are not referenced by anyone, and the LTO might eliminate them. This patch fixes the issue. Fixes a bug reported in https://bugs.llvm.org/show_bug.cgi?id=43927 Differential Revision: https://reviews.llvm.org/D69985
* ELF: Discard .ARM.exidx sections for empty functions instead of misordering ↵Peter Collingbourne2019-11-041-0/+41
| | | | | | | | | | | | | | | them. The logic added in r372781 caused ARMExidxSyntheticSection::addSection() to return false for exidx sections without a link order dep that passed isValidExidxSectionDep(). This included exidx sections for empty functions. As a result, such exidx sections would end up treated like ordinary sections and would end up being laid out before the ARMExidxSyntheticSection, most likely in the wrong order relative to the exidx entries in the ARMExidxSyntheticSection, breaking the orderedness invariant relied upon by unwinders. Fix this by simply discarding such sections. Differential Revision: https://reviews.llvm.org/D69744
* Warn when an output section name is longer than 8 charactersReid Kleckner2019-11-011-2/+12
| | | | | | | | | | | | | | Recent versions of Microsoft's dumpbin tool cannot handle such PE files. LLVM tools and GNU tools can, and use this to encode long section names like ".debug_info", which is commonly used for DWARF. Don't do this in mingw mode or when -debug:dwarf is passed, since the user probably wants long section names for DWARF sections. PR43754 Reviewers: ruiu, mstorsjo Differential Revision: https://reviews.llvm.org/D69594
* [ELF][test] Change references of %T to %t.dirFangrui Song2019-10-3011-50/+57
| | | | | | | | | | | | Test files in the same directory share the same %T. %T is easy to misuse and cause race conditions (when running concurrently) so it has been deprecated since D48842 (see docs/CommandGuide/lit.rst). While here, add `rm -rf %t.dir` so that tests cannot depend on old files lying around. Reviewed By: jhenderson, ruiu Differential Revision: https://reviews.llvm.org/D69572
* [LLD] - Fix a test after obj2yaml change.Georgii Rymar2019-10-301-6/+3
| | | | | I am not sure why obj2yaml is used to check the linkers output, but anyways, the format was changed in https://reviews.llvm.org/rG6e779e953e9d.
* [WebAssembly][lld] Fix for static linking of PIC codeSam Clegg2019-10-291-1/+1
| | | | | | | | | | | When statically linking PIC code we create an internalized __memory_base so that memory-base-relative relocation work correctly. The value of this global should be zero, and not the globalBase since the globalBase offset is already taken into account by getVirtualAddress. Fixes: https://github.com/emscripten-core/emscripten/issues/9013 Differential Revision: https://reviews.llvm.org/D69600
* [LLD][ELF] Support --[no-]mmap-output-file with F_no_mmapNick Terrell2019-10-291-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add a flag `F_no_mmap` to `FileOutputBuffer` to support `--[no-]mmap-output-file` in ELF LLD. LLD currently explicitly ignores this flag for compatibility with GNU ld and gold. We need this flag to speed up link time for large binaries in certain scenarios. When we link some of our larger binaries we find that LLD takes 50+ GB of memory, which causes memory pressure. The memory pressure causes the VM to flush dirty pages of the output file to disk. This is normally okay, since we should be flushing cold pages. However, when using BtrFS with compression we need to write 128KB at a time when we flush a page. If any page in that 128KB block is written again, then it must be flushed a second time, and so on. Since LLD doesn't write sequentially this causes write amplification. The same 128KB block will end up being flushed multiple times, causing the linker to many times more IO than necessary. We've observed 3-5x faster builds with -no-mmap-output-file when we hit this scenario. The bad scenario only applies to compressed filesystems, which group together multiple pages into a single compressed block. I've tested BtrFS, but the problem will be present for any compressed filesystem on Linux, since it is caused by the VM. Silently ignoring --no-mmap-output-file caused a silent regression when we switched from gold to lld. We pass --no-mmap-output-file to fix this edge case, but since lld silently ignored the flag we didn't realize it wasn't being respected. Benchmark building a 9 GB binary that exposes this edge case. I linked 3 times with --mmap-output-file and 3 times with --no-mmap-output-file and took the average. The machine has 24 cores @ 2.4 GHz, 112 GB of RAM, BtrFS mounted with -compress-force=zstd, and an 80% full disk. | Mode | Time | |---------|-------| | mmap | 894 s | | no mmap | 126 s | When compression is disabled, BtrFS performs just as well with and without mmap on this benchmark. I was unable to reproduce the regression with any binaries in lld-speed-test. Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D69294
* [lld] [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACKMichał Górny2019-10-291-0/+5
| | | | | | | | | Add a new '-z nognustack' option that suppresses emitting PT_GNU_STACK segment. This segment is not supported at all on NetBSD (stack is always non-executable), and the option is meant to be used to disable emitting it. Differential Revision: https://reviews.llvm.org/D56554
* Crt files are special cased by name when dealing with ctor and dtorSterling Augustine2019-10-251-3/+15
| | | | | | | | | | | | | | sections, but the current code misses certain variants. In particular, those named when clang takes the code path in clang/lib/Driver/ToolChain.cpp:416, where crtfiles are named: clang_rt.<component>-<arch>-<env>.<suffix> Previously, the code only handled: clang_rt.<component>.<suffix> <component>.<suffix> This revision fixes that.
* [LLD][ELF] - Update test case after yaml2obj change.georgerim2019-10-251-0/+1
| | | | | SHT_NOTE needs at least an empty "Content" in the YAML description. Should fix http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast
* [ELF] -r: fix crash when processing a SHT_REL[A] that relocates a SHF_MERGE ↵Fangrui Song2019-10-241-0/+23
| | | | | | | | | | | | | | | | | | | | 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][ELF] - Update tests after yaml2obj tool update.George Rimar2019-10-202-2/+0
| | | | | | yaml2obj doesn't create .symtab by default anymore. llvm-svn: 375360
* [WebAssembly] Allow multivalue signatures in object filesThomas Lively2019-10-1818-64/+89
| | | | | | | | | | | | | | | | | Summary: Also changes the wasm YAML format to reflect the possibility of having multiple return types and to put the returns after the params for consistency with the binary encoding. Reviewers: aheejin, sbc100 Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, arphaman, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69156 llvm-svn: 375283
* [LLD] [COFF] Try to report source locations for duplicate symbolsMartin Storsjo2019-10-185-9/+266
| | | | | | | | | | | | | | | | | | | | | | | This fixes the second part of PR42407. For files with dwarf debug info, it manually loads and iterates .debug_info to find the declared location of variables, to allow reporting them. (This matches the corresponding code in the ELF linker.) For functions, it uses the existing getFileLineDwarf which uses LLVMSymbolizer for translating addresses to file lines. In object files with codeview debug info, only the source location of duplicate functions is printed. (And even there, only for the first input file. The getFileLineCodeView function requires the object file to be fully loaded and initialized to properly resolve source locations, but duplicate symbols are reported at a stage when the second object file isn't fully loaded yet.) Differential Revision: https://reviews.llvm.org/D68975 llvm-svn: 375218
* [lld][test] Speculative fix for lld+windows failuresJordan Rupprecht2019-10-171-2/+2
| | | | | | | | This updates some more places using `%T` to use `%/T` for path normalization. If this does not work, this and r375126 should be reverted together. llvm-svn: 375131
* [lld][test] Fix use of escape character in an lld test on WindowsJordan Rupprecht2019-10-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Glob support was improved to accept `\` as an escape character in r375051, but reverted as r375052 due to a failure in this test on Windows. The reason this failure seems Windows specific is because the path separator `\` is currently being relied on to be interpreted literally instead of as an escape character. Per documentation on linker input section wildcard patterns, this seems to be a bug in lld accepting `\` as a literal instead of an escape character. For example: ``` SECTIONS{ .foo :{ /path/to/foo.o(.foo) }} # OK: standard UNIX path SECTIONS{ .foo :{ C:/path/to/foo.o(.foo) }} # OK: windows accepts slashes in either direction SECTIONS{ .foo :{ C:\\path\\to\\foo.o(.foo) }} # OK: escape character used to match a literal \ SECTIONS{ .foo :{ C:\path\to\foo.o(.foo) }} # BAD: this actually matches the path C:pathtofoo.o(.foo) ``` This avoids the problem in the test by using `%/T` in place of `%T` to normalize the path separator to `/`, which windows should also accept. This patch just fixes the test, and glob support will be be relanded separately. For a sample buildbot error, see: http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11578/steps/stage%201%20check/logs/stdio Reviewers: evgeny777, ruiu, MaskRay, espindola Reviewed By: ruiu, MaskRay Subscribers: emaste, arichardson, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69074 llvm-svn: 375126
* [LLD][ELF] - Update test cases after llvm-readobj output format change.George Rimar2019-10-1715-37/+37
| | | | | | | | | | | The change was: SHT_GNU_verdef { -> VersionDefinitions [ SHT_GNU_verneed { -> VersionRequirements [ Version symbols [ -> VersionSymbols [ EH_FRAME Header [ -> EHFrameHeader { llvm-svn: 375096
* [lld][WebAssebmly] Preserve custom import attributes with LTOSam Clegg2019-10-173-0/+50
| | | | | | | | | | | | | | | | | | | Undefined symbols in WebAssembly can come with custom `import-module` and `import-field` attributes. However when reading symbols from bitcode object files during LTO those curtom attributes are not available. Once we compile the LTO object and read in the symbol table from the object file we have access to these custom attributes. In this case, when undefined symbols are added and a symbol already exists in the SymbolTable we can't simple return it, we may need to update the symbol's attributes. Fixes: PR43211 Differential Revision: https://reviews.llvm.org/D68959 llvm-svn: 375081
* [lld][WebAssembly] Fix for weak references to data symbols in archivesSam Clegg2019-10-171-3/+23
| | | | | | | | | | | | | Fix a bug where were not handling relocations against weakly undefined data symbol. Add a test for this case. Also ensure that the weak references to data symbols are not pulled in from archive files by default (but are if `-u <name>` is added to the command line). Fixes: PR43696 Differential Revision: https://reviews.llvm.org/D69073 llvm-svn: 375077
* [WebAssembly] Elide data segments for .bss sectionsThomas Lively2019-10-157-43/+43
| | | | | | | | | | | | | | | | | | | Summary: WebAssembly memories are zero-initialized, so when module does not import its memory initializing .bss sections is guaranteed to be a no-op. To reduce binary size and initialization time, .bss sections are simply not emitted into the final binary unless the memory is imported. Reviewers: sbc100 Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68965 llvm-svn: 374940
* [lld][WebAssembly] Fix static linking of -fPIC code with external undefined dataJames Clarke2019-10-151-3/+16
| | | | | | | | | | | | | | Reviewers: ruiu, sbc100 Reviewed By: sbc100 Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68991 llvm-svn: 374913
* [lld] Check for branch range overflows.Sid Manning2019-10-151-0/+31
| | | | | | Differential Revision: https://reviews.llvm.org/D68875 llvm-svn: 374891
* [llvm-objdump] Adjust spacing and field width for --section-headersJordan Rupprecht2019-10-142-3/+3
| | | | | | | | | | | | | | | | | | | Summary: - Expand the "Name" column past 13 characters when any of the section names are longer. Current behavior is a staggard output instead of a nice table if a single name is longer. - Only print the required number of hex chars for addresses (i.e. 8 characters for 32-bit, 16 characters for 64-bit) - Fix trailing spaces Reviewers: grimar, jhenderson, espindola Reviewed By: grimar Subscribers: emaste, sbc100, arichardson, aheejin, seiya, llvm-commits, MaskRay Tags: #llvm Differential Revision: https://reviews.llvm.org/D68730 llvm-svn: 374795
* [LLD][ELF] - Update test cases after llvm-readobj change.George Rimar2019-10-1112-182/+139
| | | | | | https://reviews.llvm.org/D68704 changed the output format. llvm-svn: 374542
* Change test case so that it accepts backslashes in file path, in the case ↵Amy Huang2019-10-101-2/+2
| | | | | | that the test runs on Windows llvm-svn: 374473
* [PDB] Fix bug when using multiple PCH header objects with the same name.Zachary Turner2019-10-106-2/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | A common pattern in Windows is to have all your precompiled headers use an object named stdafx.obj. If you've got a project with many different static libs, you might use a separate PCH for each one of these. During the final link step, a file from A might reference the PCH object from A, but it will have the same name (stdafx.obj) as any other PCH from another project. The only difference will be the path. For example, A might be A/stdafx.obj while B is B/stdafx.obj. The existing algorithm checks only the filename that was passed on the command line (or stored in archive), but this is insufficient in the case where relative paths are used, because depending on the command line object file / library order, it might find the wrong PCH object first resulting in a signature mismatch. The fix here is to simply check whether the absolute path of the PCH object (which is stored in the input obj file for the file that references the PCH) *ends with* the full relative path of whatever is specified on the command line (or is in the archive). Differential Revision: https://reviews.llvm.org/D66431 llvm-svn: 374442
* Use error instead of fatal to report usage errorsRui Ueyama2019-10-101-0/+9
| | | | | | Differential Revision: https://reviews.llvm.org/D68768 llvm-svn: 374297
* [LLD] [MinGW] Look for other library patterns with -lMartin Storsjo2019-10-101-0/+13
| | | | | | | | | | | | | | | | | GNU ld looks for a number of other patterns than just lib<name>.dll.a and lib<name>.a. GNU ld does support linking directly against a DLL without using an import library. If that's the only match for a -l argument, point out that the user needs to use an import library, instead of leaving the user with a puzzling message about the -l argument not being found at all. Also convert an existing case of fatal() into error(). Differential Revision: https://reviews.llvm.org/D68689 llvm-svn: 374292
* [LLD] [MinGW] Add a testcase for -l:name style library options. NFC.Martin Storsjo2019-10-101-0/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D68688 llvm-svn: 374291
* Improve error message for bad SHF_MERGE sectionsRui Ueyama2019-10-102-2/+2
| | | | | | | | This patch adds a section name to error messages. Differential Revision: https://reviews.llvm.org/D68758 llvm-svn: 374290
* Use lld-link instead of llvm-dlltool to create an implibRui Ueyama2019-10-091-1/+1
| | | | | | Suggested by Martin Storsjö. llvm-svn: 374142
* [lld] Don't create hints-section if Hint/Name Table is emptyRui Ueyama2019-10-092-0/+21
| | | | | | | | | | | Fixes assert in addLinkerModuleCoffGroup() when using by-ordinal imports only. Patch by Stefan Schmidt. Differential revision: https://reviews.llvm.org/D68352 llvm-svn: 374140
* [lld][Hexagon] Support PLT relocation R_HEX_B15_PCREL_X/R_HEX_B9_PCREL_XSid Manning2019-10-082-23/+155
| | | | | | | | These are sometimes generated by tail call optimizations. Differential Revision: https://reviews.llvm.org/D66542 llvm-svn: 374052
* Use /dev/null for tests that we do not need outputsRui Ueyama2019-10-081-8/+8
| | | | llvm-svn: 374023
* Report error if -export-dynamic is used with -rRui Ueyama2019-10-082-6/+4
| | | | | | | | | | | | | The combination of the two flags doesn't make sense. And other linkers seem to just ignore --export-dynamic if --relocatable is given, but we probably should report it as an error to let users know that is an invalid combination. Fixes https://bugs.llvm.org/show_bug.cgi?id=43552 Differential Revision: https://reviews.llvm.org/D68441 llvm-svn: 374022
* [LLD] [COFF] Always demangle the __imp_ prefix to __declspec(dllimport)Martin Storsjo2019-10-044-3/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D68017 llvm-svn: 373781
* Revert r371732: "lld-link: Fix tests that do not run on macOS after r371729."Martin Storsjo2019-10-041-1/+1
| | | | | | This commit should be reverted along with r371729. llvm-svn: 373713
* [MinGW] Add --reproduce optionRui Ueyama2019-10-041-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D68382 llvm-svn: 373705
* Add /reproduce option to lld/COFFRui Ueyama2019-10-041-0/+8
| | | | | | | | | | | This patch adds /reproduce:<path> option to lld/COFF. This is an lld-specific option, so we can name it freely. I chose /reproduce over other names (e.g. /lldlinkrepro) for consistency with other lld ports. Differential Revision: https://reviews.llvm.org/D68381 llvm-svn: 373704
* Revert r371729: lld-link: Make /linkrepro: take a filename, not a directory.Rui Ueyama2019-10-043-6/+6
| | | | | | | | | | This reverts commit r371729 because /linkrepro option also exists in Microsoft link.exe and their linker takes not a filename but a directory name as an argument for /linkrepro. Differential Revision: https://reviews.llvm.org/D68378 llvm-svn: 373703
* [llvm-objdump] Further rearrange llvm-objdump sections for compatabilityJordan Rupprecht2019-10-0341-233/+233
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: rL371826 rearranged some output from llvm-objdump for GNU objdump compatability, but there still seem to be some more. I think this rearrangement is a little closer. Overview of the ordering which matches GNU objdump: * Archive headers * File headers * Section headers * Symbol table * Dwarf debugging * Relocations (if `--disassemble` is not used) * Section contents * Disassembly Reviewers: jhenderson, justice_adams, grimar, ychen, espindola Reviewed By: jhenderson Subscribers: aprantl, emaste, arichardson, jrtc27, atanasyan, seiya, llvm-commits, MaskRay Tags: #llvm Differential Revision: https://reviews.llvm.org/D68066 llvm-svn: 373671
* [mips] Use llvm-readobj `-A` flag in test cases. NFCSimon Atanasyan2019-10-0336-72/+69
| | | | llvm-svn: 373589
* Add missing REQUIRES: arm.Peter Collingbourne2019-10-011-0/+1
| | | | llvm-svn: 373357
* ELF: Add .interp synthetic sections first in createSyntheticSections().Peter Collingbourne2019-10-013-4/+28
| | | | | | | | | | | | | | | | | | | | | | Our .interp section is not a SyntheticSection. As a result, it terminates the loop in removeUnusedSyntheticSections(). This has at least two consequences: - The synthetic .bss and .bss.rel.ro sections are always present in dynamically linked executables, even when they are not needed. - The synthetic .ARM.exidx (and possibly other) sections are always present in partitions other than the last one, even when not needed. .ARM.exidx in particular is problematic because it assumes that its list of code sections is non-empty in getLinkOrderDep(), which can lead to a crash if the partition does not have any code sections. Fix these problems by moving the creation of the .interp sections to the top of createSyntheticSections(). While here, make the code a little less error-prone by changing the add() lambdas to take a SyntheticSection instead of an InputSectionBase. Differential Revision: https://reviews.llvm.org/D68256 llvm-svn: 373347
* ELF: Don't merge SHF_LINK_ORDER sections for different output sections in ↵Peter Collingbourne2019-09-301-0/+36
| | | | | | | | | | | | | | | | | | | | | relocatable links. Merging SHF_LINK_ORDER sections can affect semantics if the sh_link fields point to different sections. Specifically, for SHF_LINK_ORDER sections, the sh_link field acts as a reverse dependency from the linked section, causing the SHF_LINK_ORDER section to be included if the linked section is included. Merging sections with different sh_link fields will cause the entire contents of the SHF_LINK_ORDER section to be associated with a single (arbitrarily chosen) output section, whereas the correct semantics are for the individual pieces of the SHF_LINK_ORDER section to be associated with their linked output sections. As a result we can end up incorrectly dropping SHF_LINK_ORDER section contents or including the wrong section contents, depending on which linked sections were chosen. Differential Revision: https://reviews.llvm.org/D68094 llvm-svn: 373255
* Revert "[MC] Emit unused undefined symbol even if its binding is not set"Nico Weber2019-09-302-6/+6
| | | | | | This reverts r373168. It caused PR43511. llvm-svn: 373242
* [ELF][test] Change llvm-readobj --arm-attributes to --arch-specific after ↵Fangrui Song2019-09-301-3/+3
| | | | | | r373125 llvm-svn: 373178
* [MC] Emit unused undefined symbol even if its binding is not setFangrui Song2019-09-292-6/+6
| | | | | | | | | | | | | | | | | | | | | | | For the following two cases, we currently suppress the symbols. This patch emits them (compatible with GNU as). * `test2_a = undef`: if `undef` is otherwise unused. * `.hidden hidden`: if `hidden` is unused. This is the main point of the patch, because omitting the symbol would cause a linker semantic difference. It causes a behavior change that is not compatible with GNU as: .weakref foo1, bar1 When neither foo1 nor bar1 is used, we now emit bar1, which is arguably more consistent. Another change is that we will emit .TOC. for .TOC.@tocbase . For this directive, suppressing .TOC. can be seen as a size optimization, but we choose to drop it for simplicity and consistency. llvm-svn: 373168
OpenPOWER on IntegriCloud