summaryrefslogtreecommitdiffstats
path: root/lld/test/ELF
Commit message (Collapse)AuthorAgeFilesLines
...
* [mips] Remove trailing whitespaces from the test case. NFCSimon Atanasyan2019-02-191-3/+3
| | | | llvm-svn: 354315
* [mips] Create LA25 thunks for MIPS R6 codeSimon Atanasyan2019-02-191-23/+47
| | | | | | | | MIPS R6 code uses the `R_MIPS_PC26_S2` relocation for calls which might cross boundaries of non-PIC-to-PIC code. We need to create a LA25 thunks for that case. llvm-svn: 354312
* [MIPS] Handle cross-mode (regular <-> microMIPS) jumpsSimon Atanasyan2019-02-194-7/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch solves two tasks: 1. MIPS ABI allows to mix regular and microMIPS code and perform cross-mode jumps. Linker needs to detect such cases and replace jump/branch instructions by their cross-mode equivalents. 2. Other tools like dunamic linkers need to recognize cases when dynamic table entries, e_entry field of an ELF header etc point to microMIPS symbol. Linker should provide such information. The first task is implemented in the `MIPS<ELFT>::relocateOne()` method. New routine `fixupCrossModeJump` detects ISA mode change, checks and replaces an instruction. The main problem is how to recognize that relocation target is microMIPS symbol. For absolute and section symbols compiler or assembler set the less-significant bit of the symbol's value or sum of the symbol's value and addend. And this bit signals to linker about microMIPS code. For global symbols compiler cannot do the same trick because other tools like, for example, disassembler wants to know an actual position of the symbol. So compiler sets STO_MIPS_MICROMIPS flag in the `st_other` field. In `MIPS<ELFT>::relocateOne()` method we have a symbol's value only and cannot access any symbol's attributes. To pass type of the symbol (regular/microMIPS) to that routine as well as other places where we write a symbol value as-is (.dynamic section, `Elf_Ehdr::e_entry` field etc) we set when necessary a less-significant bit in the `getSymVA` function. Differential revision: https://reviews.llvm.org/D40147 llvm-svn: 354311
* [PPC64] Preserve LocalEntry when linkingRui Ueyama2019-02-151-0/+47
| | | | | | | | | | | | | On PowerPC64, it is necessary to keep the LocalEntry bits in st_other, especially when -r is used. Otherwise, when the resulting object is used in a posterior linking, LocalEntry info will be unavailable and functions may be called through the wrong entrypoint. Patch by Leandro Lupori. Differential Revision: https://reviews.llvm.org/D56782 llvm-svn: 354184
* LLD/AMDGPU: Preserve ABI version during linking ELF for AMDGPUKonstantin Zhuravlyov2019-02-142-0/+21
| | | | | | Differential Revision: https://reviews.llvm.org/D58026 llvm-svn: 354086
* Improve error message for unknown relocations.Rui Ueyama2019-02-142-3/+3
| | | | | | | | | | | | Previously, we showed the following message for an unknown relocation: foo.o: unrecognized reloc 256 This patch improves it so that the error message includes a symbol name: foo.o: unknown relocation (256) against symbol bar llvm-svn: 354040
* ELF: Allow GOT relocs pointing to non-preemptable ifunc to resolve to an ↵Peter Collingbourne2019-02-139-25/+146
| | | | | | | | | | | | | | | | IRELATIVE where possible. Non-GOT non-PLT relocations to non-preemptible ifuncs result in the creation of a canonical PLT, which now takes the identity of the IFUNC in the symbol table. This (a) ensures address consistency inside and outside the module, and (b) fixes a bug where some of these relocations end up pointing to the resolver. Fixes (at least) PR40474 and PR40501. Differential Revision: https://reviews.llvm.org/D57371 llvm-svn: 353981
* Recover elf32-bigmips and elf32-powerpc support in LLDRui Ueyama2019-02-132-0/+40
| | | | | | | | | | | | | This fixes a 7.0 -> 8.0 regression when parsing OUTPUT_FORMAT("elf32-powerpc"); or elf32-bigmips directive in ldscripts as well as an unknown emulation error when lld is invoked by clang due to missed elf32ppclinux case. Patch by vit9696 Differential Revision: https://reviews.llvm.org/D58005 llvm-svn: 353968
* Show "Unknown -z option" error message even if --version or --help are given.Rui Ueyama2019-02-131-0/+1
| | | | | | | | | | Previously, we validated -z options after we process --version or --help flags. So, if one of these flags is given, we wouldn't show an "unknown -z option" error. This patch fixes that behavior. Differential Revision: https://reviews.llvm.org/D55446 llvm-svn: 353967
* [PPC64] Update tests to reflect change in printing of call operand. [NFC]Sean Fertile2019-02-128-14/+13
| | | | | | | The printing of branch operands for call instructions was changed to properly handle negative offsets. Updating the tests to reflect that. llvm-svn: 353866
* lld: unquote possibly quoted `EXTERN("symbol")` entry in linker script.Rui Ueyama2019-02-112-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | gold accepts quoted strings. binutils requires quoted strings for some kinds of symbols, e.g.: it accepts quoted symbols with @ in name: $ echo 'EXTERN("__libc_start_main@@GLIBC_2.2.5")' > a.script $ g++ a.script /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status but rejects them if unquoted: $ echo 'EXTERN(__libc_start_main@@GLIBC_2.2.5)' > a.script $ g++ a.script a.script: file not recognized: File format not recognized collect2: error: ld returned 1 exit status To maintain compatibility with existing linker scripts support quoted strings in lld as well. Patch by Lucian Adrian Grijincu. Differential Revision: https://reviews.llvm.org/D57987 llvm-svn: 353756
* Convert CRLF. NFC.Rui Ueyama2019-02-111-9/+9
| | | | llvm-svn: 353751
* [LLD][ELF] - Update test case after yaml2obj change. NFCI.George Rimar2019-02-091-1/+4
| | | | | | | .dynamic section format accepted by yaml2obj was changed in r353606 llvm-svn: 353607
* [ELF] Delete a comment that is no longer correct. Fix a typo. NFCFangrui Song2019-02-091-1/+0
| | | | llvm-svn: 353605
* [LLD][ELF] Ensure tests use -o /dev/null instead of attempting to write to ↵David L. Jones2019-02-091-3/+3
| | | | | | | | the bin directory. [NFC] This error was introduced in r353508. llvm-svn: 353602
* [LLD][ELF]Add test for missing thin archive memberJames Henderson2019-02-081-0/+24
| | | | | | | | | | | | The code producing error messages relating to missing thin archive members was missing any testing as far as I could see, so this patch adds a test for it. Reviewed by: ruiu Differential Revision: https://reviews.llvm.org/D57899 llvm-svn: 353508
* Fix a bug in R_X86_64_PC{8,16} relocation handling.Rui Ueyama2019-02-072-4/+14
| | | | | | | | R_X86_64_PC{8,16} relocations are sign-extended, so when we check for relocation overflow, we had to use checkInt instead of checkUInt. I confirmed that GNU linkers create the same output for the test case. llvm-svn: 353437
* [LLD][ELF] - Set DF_STATIC_TLS flag for X64 targetGeorge Rimar2019-02-074-33/+51
| | | | | | | | | | | | This is the same as D57749, but for x64 target. "ELF Handling For Thread-Local Storage" p41 says (https://www.akkadia.org/drepper/tls.pdf): R_X86_64_GOTTPOFF relocation is used for IE TLS models. Hence if linker sees this relocation we should add DF_STATIC_TLS flag. Differential revision: https://reviews.llvm.org/D57821 llvm-svn: 353378
* 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
* [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
* [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
* [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
* [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
* 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
* 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
* 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
* [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
* 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
* [ELF][X86_64] Fix corrupted LD -> LE optimization for TLS without PLTPeter Wu2019-01-161-0/+88
| | | | | | | | | | | | | | | | | | | | The LD -> LE optimization for Thread-Local Storage without PLT requires an additional "66" prefix, otherwise the next instruction will be corrupted, causing runtime misbehavior (crashes) of the linked object. The other (GD -> IE/LD) optimizations are the same with or without PLT, but add tests for completeness. The instructions are copied from https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x86-64-psABI-1.0.pdf#subsection.11.1.2 This does not try to address ILP32 (x32) support. Fixes https://bugs.llvm.org/show_bug.cgi?id=37303 Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D56779 llvm-svn: 351396
* [ELF][AArch64] Add R_AARCH64_PLT_PAGE_PC to isRelExprPeter Smith2019-01-161-0/+44
| | | | | | | | | | | | | | | | | | As a follow on to D56666 (r351186) there is a case when taking the address of an ifunc when linking -pie that can generate a spurious can't create dynamic relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol in readonly segment. Specifically the case is where the ifunc is in the same translation unit as the address taker, so given -fpie the compiler knows the ifunc is defined in the executable so it can use a non-got-generating relocation. The error message is due to R_AARCH64_PLT_PAGE_PC not being added to isRelExpr, its non PLT equivalent R_AARCH64_PAGE_PC is already in isRelExpr. Differential Revision: https://reviews.llvm.org/D56724 llvm-svn: 351335
* [ELF] Implement option to force PIC compatible ThunksPeter Smith2019-01-161-0/+87
| | | | | | | | | | | | | | | | | By default LLD will generate position independent Thunks when the --pie or --shared option is used. Reference to absolute addresses is permitted in other cases. For some embedded systems position independent thunks are needed for code that executes before the MMU has been set up. The option --pic-veneer is used by ld.bfd to force position independent thunks. The patch adds --pic-veneer as the option is needed for the Linux kernel on Arm. fixes pr39886 Differential Revision: https://reviews.llvm.org/D55505 llvm-svn: 351326
* Do not emit a corrupt symbol table entry for .rela_iplt_{start,end}.Rui Ueyama2019-01-151-0/+16
| | | | | | | | | | | | | If .rela.iplt does not exist, we used to emit a corrupt symbol table that contains two symbols, .rela_iplt_{start,end}, pointing to a nonexisting section. This patch fixes the issue by setting section index 0 to the symbols if .rel.iplt section does not exist. Differential Revision: https://reviews.llvm.org/D56623 llvm-svn: 351218
* [ELF][AArch64] Add missing PLT relocations to isStaticLinkTimeConstantPeter Smith2019-01-151-0/+40
| | | | | | | | | | | | | r347650 fixed pr38074 for AArch64 for static linking. It added two new RelExpr instances R_AARCH64_GOT_PAGE_PC_PLT and R_GOT_PLT. These need to be added to isStaticLinkTimeConstant so that the address of an ifunc can be taken when building a shared library. fixes pr40250 Differential Revision: https://reviews.llvm.org/D56666 llvm-svn: 351186
* Remove an external test file. NFC.Rui Ueyama2019-01-102-9/+5
| | | | llvm-svn: 350855
* TrapInstr must be 4 bytes long. Currently we write two zeros on every two bytes.Rui Ueyama2019-01-101-0/+3
| | | | llvm-svn: 350853
* [LLD][ELF] - Fix tests after r350840.George Rimar2019-01-107-8/+1
| | | | | | | | D56076 (r350840) changed the llvm-objdump output. This is a follow up commit to fix LLD test cases. llvm-svn: 350842
OpenPOWER on IntegriCloud