summaryrefslogtreecommitdiffstats
path: root/lld/test
Commit message (Collapse)AuthorAgeFilesLines
...
* [MinGW] Add --insert-timestamp as complement to the --no-insert-timestamp optionMartin Storsjo2019-02-061-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D57808 llvm-svn: 353342
* Support R_X86_64_PC8 and R_X86_64_PC16.Rui Ueyama2019-02-061-0/+21
| | | | | | | | They are defined by the x86-64 ELF ABI standard. Differential Revision: https://reviews.llvm.org/D57799 llvm-svn: 353314
* Recommit r353293 "[LLD][ELF] - Set DF_STATIC_TLS flag for i386 target."George Rimar2019-02-068-71/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the following changes: 1) Compilation fix: std::atomic<bool> HasStaticTlsModel = false; -> std::atomic<bool> HasStaticTlsModel{false}; 2) Adjusted the comment in code. Initial commit message: DF_STATIC_TLS flag indicates that the shared object or executable contains code using a static thread-local storage scheme. Patch checks if IE/LE relocations were used to check if the code uses a static model. If so it sets the DF_STATIC_TLS flag. Differential revision: https://reviews.llvm.org/D57749 ---- Modified : /lld/trunk/ELF/Arch/X86.cpp Modified : /lld/trunk/ELF/Config.h Modified : /lld/trunk/ELF/SyntheticSections.cpp Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model1.s Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model2.s Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model3.s Added : /lld/trunk/test/ELF/Inputs/i386-static-tls-model4.s Added : /lld/trunk/test/ELF/i386-static-tls-model.s Modified : /lld/trunk/test/ELF/i386-tls-ie-shared.s Modified : /lld/trunk/test/ELF/tls-dynamic-i686.s Modified : /lld/trunk/test/ELF/tls-opt-iele-i686-nopic.s llvm-svn: 353299
* Revert r353293 "[LLD][ELF] - Set DF_STATIC_TLS flag for i386 target."George Rimar2019-02-068-127/+71
| | | | | | | | | | | | It broke BB: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/43450 http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/27891 Error is: tools/lld/ELF/Config.h:84:41: error: copying member subobject of type 'std::atomic<bool>' invokes deleted constructor std::atomic<bool> HasStaticTlsModel = false; llvm-svn: 353297
* [LLD][ELF] - Set DF_STATIC_TLS flag for i386 target.George Rimar2019-02-068-71/+127
| | | | | | | | | | | | DF_STATIC_TLS flag indicates that the shared object or executable contains code using a static thread-local storage scheme. Patch checks if IE/LE relocations were used to check if the code uses a static model. If so it sets the DF_STATIC_TLS flag. Differential revision: https://reviews.llvm.org/D57749 llvm-svn: 353293
* [ELF][ARM] Add test case that will fail if toPlt() is removed [NFC]Peter Smith2019-02-061-0/+94
| | | | | | | | | | | | | | | | | | When a thunk is created to a PLT entry, the call to the thunk is converted to a non-plt expression with fromPlt(). If the thunk becomes unusable we retarget the relocation back to its original target and try again. When we do this we need to make sure that we restore the PLT form of the expression with toPlt(). This change adds a test case that will fail if toPlt() is removed. We need to have a call to a preemptible symbol defined within the link unit. If toPlt() is removed then the relocation to the thunk to the PLT entry for the preemptible symbol will be retargeted to the preemptible symbol itself instead of its PLT entry. Differential Revision: https://reviews.llvm.org/D57743 llvm-svn: 353285
* [wasm-ld] Fix wasm trace test to use %t for temporary files.David L. Jones2019-02-061-2/+2
| | | | llvm-svn: 353272
* [WebAssembly] Implement --trace and --trace-symbolSam Clegg2019-02-062-0/+31
| | | | | | Differential Revision: https://reviews.llvm.org/D57725 llvm-svn: 353264
* [PPC64] Delete the unnecessary __tls_get_addr from ppc64-tls-ld-le.sFangrui Song2019-02-061-3/+1
| | | | | | | The definition is harmful here as it suppresses R_PPC64_REL24 which is supposed to follow R_PPC64_TLSLD. llvm-svn: 353263
* [PPC64] Set the number of relocations processed for R_PPC64_TLS[GL]D to 2Fangrui Song2019-02-062-8/+0
| | | | | | | | | | | | | | | | | | | | | | Summary: R_PPC64_TLSGD and R_PPC64_TLSLD are used as markers on TLS code sequences. After GD-to-IE or GD-to-LE relaxation, the next relocation R_PPC64_REL24 should be skipped to not create a false dependency on __tls_get_addr. When linking statically, the false dependency may cause an "undefined symbol: __tls_get_addr" error. R_PPC64_GOT_TLSGD16_HA R_PPC64_GOT_TLSGD16_LO R_PPC64_TLSGD R_TLSDESC_CALL R_PPC64_REL24 __tls_get_addr Reviewers: ruiu, sfertile, syzaara, espindola Reviewed By: sfertile Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits, tamur Tags: #llvm Differential Revision: https://reviews.llvm.org/D57673 llvm-svn: 353262
* [ELF] Fix typo in test/ELF/trace.sSam Clegg2019-02-061-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D57796 llvm-svn: 353254
* [PDB] Remove dots and normalize slashes with /PDBSOURCEPATH.Zachary Turner2019-02-061-30/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | In a previous patch, I made changes so that PDBs which were generated on non-Windows platforms contained sensical paths for the host. While this is an esoteric use case, we need it to be supported for certain cross compilation scenarios especially with LLDB, which can debug things on non-Windows platforms. However, this regressed a case where you specify /PDBSOURCEPATH and use a windows-style path. Previously, we would still remove dots and canonicalize slashes to backslashes, but since my change intentionally tried to support non-backslash paths, this was broken. This patch fixes the situation by trying to guess which path style the user is specifying when /PDBSOURCEPATH is passed. It is intentionally conservative, erring on the side of a Windows path style unless absolutely certain. All dots are removed and slashes canonicalized to whatever the deduced path style is after appending the file path to the /PDBSOURCEPATH argument. Differential Revision: https://reviews.llvm.org/D57769 llvm-svn: 353250
* [llvm-readobj] Display sections that do not belong to a segment in the ↵Matt Davis2019-02-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | section-mapping Summary: The following patch adds the "None" line to the section to segment mapping dump. That line lists the sections that do not belong to any segment. I realize that this change differs from GNU readelf which does not display the latter information. I'd rather not add this "feature" under a command line option. I think that might introduce confusion, since users would have to make an additional decision as to if they want to see all of the section-to-segment map or just a subset of it. Another option is to only print the "None" line if the `--section-mapping` option is passed; however, that might also introduce some confusion, because the section-to-segment map would be different between`--program-headers` and the `--section-mapping` output. While the difference is just the "None" line, it seems that if we choose to display the segment-to-section mapping, then we should always display the whole map including the sections that do not belong to segments. ``` Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .gnu.hash 03 .init_array .fini_array .dynamic 04 .dynamic 05 .note.ABI-tag 06 .eh_frame_hdr 07 08 .init_array .fini_array .dynamic .got None .comment .symtab .strtab .shstrtab <--- THIS LINE ``` Reviewers: grimar, rupprecht, jhenderson, espindola Reviewed By: rupprecht Subscribers: khemant, emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D57700 llvm-svn: 353217
* [WebAssembly] Use wasm-ld rather than lld with -flavor in tests. NFC.Sam Clegg2019-02-052-4/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D57758 llvm-svn: 353187
* [MinGW] Hook up the --no-insert-timestamp optionMartin Storsjo2019-02-051-0/+3
| | | | | | | | | | This fixes PR40582. Patch by Georg Koppen! Differential Revision: https://reviews.llvm.org/D57679 llvm-svn: 353145
* [WebAssembly] Update test to match new readobj output. NFC.Sam Clegg2019-02-041-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D57715 llvm-svn: 353105
* [WebAssembly] Update relocation naming to match llvm change. NFC.Sam Clegg2019-02-049-170/+170
| | | | | | Differential Revision: https://reviews.llvm.org/D57698 llvm-svn: 353066
* [ELF] Default to --no-allow-shlib-undefined for executablesFangrui Song2019-02-023-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This follows the ld.bfd/gold behavior. The error check is useful as it captures a common type of ld.so undefined symbol errors as link-time errors: // a.cc => a.so (not linked with -z defs) void f(); // f is undefined void g() { f(); } // b.cc => executable with a DT_NEEDED entry on a.so void g(); int main() { g(); } // ld.so errors when g() is executed (lazy binding) or when the program is started (-z now) // symbol lookup error: ... undefined symbol: f Reviewers: ruiu, grimar, pcc, espindola Reviewed By: ruiu Subscribers: llvm-commits, emaste, arichardson Tags: #llvm Differential Revision: https://reviews.llvm.org/D57569 llvm-svn: 352943
* [COFF] Create range extension thunks for ARM64Martin Storsjo2019-02-012-16/+27
| | | | | | | | | | | | | | On ARM64, this is normally necessary only after a module exceeds 128 MB in size (while the limit for thumb is 16 MB). For conditional branches, the range limit is only 1 MB though (the same as for thumb), and for the tbz instruction, the range is only 32 KB, which allows for a test much smaller than the full 128 MB. This fixes PR40467. Differential Revision: https://reviews.llvm.org/D57575 llvm-svn: 352929
* [COFF] Fix crashes when writing a PDB after adding thunks.Martin Storsjo2019-02-011-0/+18
| | | | | | | | | | | | When writing a PDB, the OutputSection of all chunks need to be set. The thunks are added directly to OutputSection after the normal machinery that sets it for all other chunks. This fixes part of PR40467. Differential Revision: https://reviews.llvm.org/D57574 llvm-svn: 352928
* [WebAssembly] Support imports from custom module namesSam Clegg2019-02-011-0/+21
| | | | | | | | | | | | | Fixes: https://bugs.llvm.org/show_bug.cgi?id=37168 This is only a first pass at supporting these custom import modules. In the long run we most likely want to treat these kinds of symbols very differently. For example, it should not be possible to resolve such as symbol at static link type. Differential Revision: https://reviews.llvm.org/D45796 llvm-svn: 352828
* [ELF] Support --{,no-}allow-shlib-undefinedFangrui Song2019-02-011-15/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-link: Allow mixing 'discard' and 'largest' comdat selectionsNico Weber2019-01-311-2/+13
| | | | | | | | | | | | | | | | | | | cl.exe and clang-cl.exe put vftables in a 'discard' comdat when building with RTTI disabled (/GR-) but in a 'largest' comdat when building with RTTI enabled. To be able to link /GR- code with /GR code, lld-link needs to accept comdats that have this type of comdat selection conflict. For example, static libraries in the Visual Studio standard library are built with /GR, and without this it's impossible to build client code with /GR- and still link to the standard library. link.exe also accepts merging 'discard' with 'largest', and it accepts merging 'largest' with any other selection type. lld-link is still a bit stricter since it only allows merging 'largest' with 'discard' for symmetry. Differential Revision: https://reviews.llvm.org/D57515 llvm-svn: 352765
* [WebAssembly] Fix crash with LTO + relocatable + undefined symbolsSam Clegg2019-01-305-133/+169
| | | | | | | | | | | | Change the way we create the symbol table to be closer to how its done on ELF. Now the output symbol table matches the internal symtab order and includes local and undefined symbols. Fixes PR40204 Differential Revision: https://reviews.llvm.org/D56947 llvm-svn: 352645
* Recognize FreeBSD specific BFD names in OUTPUT_FORMATDimitry Andric2019-01-303-2/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: After rLLD344952 ("Add OUTPUT_FORMAT linker script directive support"), using BFD names such as `elf64-x86-64-freebsd` the `OUTPUT_FORMAT` linker script command does not work anymore, resulting in errors like: ``` ld: error: /home/dim/src/clang800-import/stand/efi/loader/arch/amd64/ldscript.amd64:2: unknown output format name: elf64-x86-64-freebsd >>> OUTPUT_FORMAT("elf64-x86-64-freebsd", "elf64-x86-64-freebsd", "elf64-x86-64-freebsd") >>> ^ ``` To fix this, recognize a `-freebsd` suffix in BFD names, and also set `Configuration::OSABI` to `ELFOSABI_FREEBSD` for those cases. Add and/or update several test cases to check for the correct results of these new `OUTPUT_FORMAT` arguments. Reviewers: ruiu, atanasyan, grimar, hokein, emaste, espindola Reviewed By: ruiu Subscribers: nemanjai, javed.absar, arichardson, krytarowski, kristof.beyls, kbarton, llvm-commits Differential Revision: https://reviews.llvm.org/D57283 llvm-svn: 352606
* lld/coff: Implement some support for the comdat selection fieldNico Weber2019-01-302-0/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLD used to handle comdats as if the selection field was always set to IMAGE_COMDAT_SELECT_ANY. This means for obj files produced by `cl /Gy`, LLD would never report a duplicate symbol error. This change: - adds validation for the Selection field (should make no difference in practice for compiler-generated obj inputs) - rejects comdats that have different Selection fields in different obj files (likewise). This is a bit more strict but also more self-consistent thank link.exe (see comment in code) - implements handling for all the selection kinds In practice, compilers only generate comdats with IMAGE_COMDAT_SELECT_NODUPLICATES (LLD now produces duplicate symbol errors for these), IMAGE_COMDAT_SELECT_ANY (no behavior change), and IMAGE_COMDAT_SELECT_LARGEST (for RTTI data; here LLD should no longer create broken executables when linking some TUs with RTTI enabled and some with it disabled – but see below). The implementation of `IMAGE_COMDAT_SELECT_LARGEST` is incomplete: If one SELECT_LARGEST comdat replaces an earlier one, the comdat symbol is replaced correctly, but the old section stays loaded and if /opt:ref is disabled (via /opt:noref or /debug) it's still written to the output. That's not ideal, but better than the current treatment of just picking any one of those comdats. I hope to fix this better later. Fixes most of PR40094. Differential Revision: https://reviews.llvm.org/D57324 llvm-svn: 352590
* lld-link: Add test I forgot to add in 332012Nico Weber2019-01-301-0/+18
| | | | | | Differential Revision: https://reviews.llvm.org/D46693 llvm-svn: 352589
* [WebAssembly] Fix undefined weak function symbols in LTO buildsSam Clegg2019-01-301-0/+20
| | | | | | | | | | Summary: Fixes PR40219 Subscribers: dschuff, mehdi_amini, inglorion, jgravelle-google, aheejin, sunfish, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D57420 llvm-svn: 352575
* [WebAssembly] Don't load weak undefined symbols from archive filesSam Clegg2019-01-291-0/+19
| | | | | | | | | | Summary: Fixes PR40494 Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D57370 llvm-svn: 352554
* lld-link: Allow backward references between associated comdatsNico Weber2019-01-291-6/+12
| | | | | | | | | | | | | | | | | References between associated comdats are invalid per COFF spec, but the newest Windows SDK contains obj files that have these references (https://bugs.chromium.org/p/chromium/issues/detail?id=925943#c13). So add back support for them and add tests for them. The old code handled them fine. This makes lld-link match the behavior of newer link.exe versions as far as I can tell. (The behavior before this change matched the behavior of older link.exe versions.) This mostly reverts r352254. Differential Revision: https://reviews.llvm.org/D57387 llvm-svn: 352508
* lld/coff: Make assoc comdat diag a bit more detailedNico Weber2019-01-282-3/+3
| | | | | | | | | Many different sections can have the same name, so include the indices of the sections mentioned in the diagnostic too. I'm debugging something I can't repro locally, maybe this will help. llvm-svn: 352428
* ELF: Set sh_info on RelaIplt to point to the IgotPlt output section.Peter Collingbourne2019-01-281-1/+4
| | | | | | | | | | | Previously we were setting it to the GotPlt output section, which is incorrect on ARM where this section is in .got. In static binaries this can lead to sh_info being set to -1 (because there is no .got.plt) which results in various tools rejecting the output file. Differential Revision: https://reviews.llvm.org/D57274 llvm-svn: 352413
* [LLD][ELF] - Update tests after r352366.George Rimar2019-01-2828-31/+31
| | | | | | | r352366 "[llvm-objdump] - Print LMAs when dumping section headers." changed the format of llvm-objdump output. We have to update the LLD tests. llvm-svn: 352372
* [COFF] Add support for the new relocation IMAGE_REL_ARM{,64}_REL32Martin Storsjo2019-01-272-7/+59
| | | | | | Differential Revision: https://reviews.llvm.org/D57292 llvm-svn: 352325
* lld: elf: discard more specific .gnu.linkonce sectionNick Desaulniers2019-01-272-1/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* lld-link: Store comdat selection in SectionChunk, reject more invalid ↵Nico Weber2019-01-261-7/+13
| | | | | | | | | | | | | | associated comdats I need the comdat selection for PR40094. To keep the patch for that smaller, I'm adding it here, and as a first application I'm using it to reject associative comdats referring to earlier associative comdats. Depends on D56929; together with that all associative comdats referring to other associative comdats are now rejected. Differential Revision: https://reviews.llvm.org/D56931 llvm-svn: 352254
* [PDB] Increase TPI hash bucket count.Zachary Turner2019-01-242-17/+27
| | | | | | | | | | | | | | | PDBs contain several serialized hash tables. In the microsoft-pdb repo published to support LLVM implementing PDB support, the provided initializes the bucket count for the TPI and IPI streams to the maximum size. This occurs in tpi.cpp L33 and tpi.cpp L398. In the LLVM code for generating PDBs, these streams are created with minimum number of buckets. This difference makes LLVM generated PDBs slower for when used for debugging. Patch by C.J. Hebert Differential Revision: https://reviews.llvm.org/D56942 llvm-svn: 352117
* Define the _fltused symbol in a couple tests post-r352076.James Y Knight2019-01-242-0/+8
| | | | | | | Normally it's defined by MSCRT, but these tests are standalone, so they need to define it themselves. llvm-svn: 352110
* Fix broken export table if .rdata is merged with .text.Rui Ueyama2019-01-241-0/+13
| | | | | | | | | | | | | | | | | | Previously, we assumed that .rdata is zero-filled, so when writing an COFF import table, we didn't write anything if the data is zero. That assumption was wrong because .rdata can be merged with .text. If .rdata is merged with .text, they are initialized with 0xcc which is a trap instruction. This patch removes that assumption from code. Should be merged to 8.0 branch as this is a regression. Fixes https://bugs.llvm.org/show_bug.cgi?id=39826 Differential Revision: https://reviews.llvm.org/D57168 llvm-svn: 352082
* lld/coff: Rename two tests from .s to .testNico Weber2019-01-242-0/+0
| | | | llvm-svn: 352074
* [PPC64] Reland r351978 'Sort .toc sections accessed with small code model ...'Sean Fertile2019-01-244-0/+190
| | | | | | | | | | | | | | | | | | | | | | | 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
* Partial support of SHT_GROUP without flagSerge Guelton2019-01-241-0/+55
| | | | | | | | | | 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
* Revert "[PPC64] Sort .toc sections accessed with small code model ..."Sean Fertile2019-01-234-190/+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-234-0/+190
| | | | | | | | | | | | | | | | | | | 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
* Disable test better.Nico Weber2019-01-231-1/+1
| | | | llvm-svn: 351952
* Disable test added in r351916.Nico Weber2019-01-231-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It doesn't pass on Windows: http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/3627 FAIL: lld :: ELF/stdout.s (1521 of 1966) ******************** TEST 'lld :: ELF/stdout.s' FAILED ******************** Script: -- : 'RUN: at line 3'; C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\llvm-mc.EXE -filetype=obj -triple=x86_64-unknown-linux C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\lld\test\ELF\stdout.s -o C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o : 'RUN: at line 4'; c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\ld.lld.EXE C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o -o - > C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1 : 'RUN: at line 5'; C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\llvm-objdump.EXE -d C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1 | C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\FileCheck.EXE C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\lld\test\ELF\stdout.s : 'RUN: at line 10'; c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\ld.lld.EXE C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o -o C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp2 : 'RUN: at line 11'; diff C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1 C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp2 -- Exit Code: 1 Command Output (stdout): -- $ ":" "RUN: at line 3" $ "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\llvm-mc.EXE" "-filetype=obj" "-triple=x86_64-unknown-linux" "C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\lld\test\ELF\stdout.s" "-o" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o" $ ":" "RUN: at line 4" $ "c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\ld.lld.EXE" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o" "-o" "-" $ ":" "RUN: at line 5" $ "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\llvm-objdump.EXE" "-d" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1" $ "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\FileCheck.EXE" "C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\lld\test\ELF\stdout.s" $ ":" "RUN: at line 10" $ "c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\ld.lld.EXE" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp.o" "-o" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp2" $ ":" "RUN: at line 11" $ "diff" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1" "C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp2" # command output: *** C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp1 --- C:\b\slave\clang-x64-windows-msvc\build\build\stage1\tools\lld\test\ELF\Output\stdout.s.tmp2 *************** *** 1 **** llvm-svn: 351949
* lld-link: Use just one code path to process associative comdats, reject some ↵Nico Weber2019-01-232-0/+141
| | | | | | | | | | | | | | | | | | | invalid associated comdats Currently, if an associative comdat appears after the comdat it's associated with it's processed immediately, else it's deferred until the end of the object file. I found this confusing to think about while working on PR40094, so this makes it so that associated comdats are always processed at the end of the object file. This seems to be perf-neutral and simpler. Now there's a natural place to reject the associated comdats referring to later associated comdats (associated comdats referring to associated comdats is invalid per COFF spec) that, so reject those. (A later patch will reject associated comdats referring to earlier comdats.) Differential Revision: https://reviews.llvm.org/D56929 llvm-svn: 351917
* MemoryBlock: Do not automatically extend a given size to a multiple of page ↵Rui Ueyama2019-01-231-2/+5
| | | | | | | | | | | | | | | | | | | | | | | size. Previously, MemoryBlock automatically extends a requested buffer size to a multiple of page size because (I believe) doing it was thought to be harmless and with that you could get more memory (on average 2KiB on 4KiB-page systems) "for free". That programming interface turned out to be error-prone. If you request N bytes, you usually expect that a resulting object returns N for `size()`. That's not the case for MemoryBlock. Looks like there is only one place where we take the advantage of allocating more memory than the requested size. So, with this patch, I simply removed the automatic size expansion feature from MemoryBlock and do it on the caller side when needed. MemoryBlock now always returns a buffer whose size is equal to the requested size. Differential Revision: https://reviews.llvm.org/D56941 llvm-svn: 351916
* FileOutputBuffer: Handle "-" as stdout.Rui Ueyama2019-01-221-0/+12
| | | | | | | | | | | | | | | | | I was honestly a bit surprised that we didn't do this before. This patch is to handle "-" as the stdout so that if you pass `-o -` to lld, for example, it writes an output to stdout instead of file `-`. I thought that we might want to handle this at a higher level than FileOutputBuffer, because if we land this patch, we can no longer create a file whose name is `-` (there's a workaround though; you can pass `./-` instead of `-`). However, because raw_fd_ostream already handles `-` as a special file name, I think it's okay and actually consistent to handle `-` as a special name in FileOutputBuffer. Differential Revision: https://reviews.llvm.org/D56940 llvm-svn: 351852
* [LLD][ELF]Fix tests for D56910James Henderson2019-01-223-5/+6
| | | | | | | | | | | r351789 changes the output of llvm-readelf --dyn-symbols. This causes 3 LLD tests to break. This patch fixes them. Reviewed by: ruiu Differential Revision: https://reviews.llvm.org/D56911 llvm-svn: 351790
OpenPOWER on IntegriCloud