summaryrefslogtreecommitdiffstats
path: root/lld
Commit message (Collapse)AuthorAgeFilesLines
...
* Follow-up to r352254: Initialize Selection field.Nico Weber2019-01-271-1/+1
| | | | | | The diagnostic there fired spuriosly due to uninitialized memory. llvm-svn: 352304
* lld: elf: discard more specific .gnu.linkonce sectionNick Desaulniers2019-01-273-2/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove dead declaration.Rui Ueyama2019-01-261-1/+0
| | | | llvm-svn: 352257
* lld-link: Store comdat selection in SectionChunk, reject more invalid ↵Nico Weber2019-01-263-12/+32
| | | | | | | | | | | | | | 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
* Simplify. NFC.Rui Ueyama2019-01-251-4/+2
| | | | llvm-svn: 352242
* [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-242-1/+28
| | | | | | | | | | | | | | | | | | 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-249-0/+232
| | | | | | | | | | | | | | | | | | | | | | | 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
* Untabify.Rui Ueyama2019-01-241-1/+1
| | | | llvm-svn: 352070
* Partial support of SHT_GROUP without flagSerge Guelton2019-01-242-22/+74
| | | | | | | | | | 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-239-232/+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-239-0/+232
| | | | | | | | | | | | | | | | | | | 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-233-18/+161
| | | | | | | | | | | | | | | | | | | 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
* COFF, ELF: ICF: Perform 2 rounds of relocation hash propagation.Peter Collingbourne2019-01-222-20/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLD's performance on PGO instrumented Windows binaries was still not great even with the fix in D56955; out of the 2m41s linker runtime, around 2 minutes were still being spent in ICF. I looked into this more closely and discovered that the vast majority of the runtime was being spent segregating .pdata sections with the following relocation chain: .pdata -> identical .text -> unique PGO counter (not eligible for ICF) This patch causes us to perform 2 rounds of relocation hash propagation, which allows the hash for the .pdata sections to incorporate the identifier from the PGO counter. With that, the amount of time spent in ICF was reduced to about 2 seconds. I also found that the same change led to a significant ICF performance improvement in a regular release build of Chromium's chrome_child.dll, where ICF time was reduced from around 1s to around 700ms. With the same change applied to the ELF linker, median of 100 runs for lld-speed-test/chrome reduced from 4.53s to 4.45s on my machine. I also experimented with increasing the number of propagation rounds further, but I did not observe any further significant performance improvements linking Chromium or Firefox. Differential Revision: https://reviews.llvm.org/D56986 llvm-svn: 351899
* COFF, ELF: Adjust ICF hash computation to account for self relocations.Peter Collingbourne2019-01-222-2/+2
| | | | | | | | | | | | | | | | It turns out that sections in PGO instrumented object files on Windows contain a large number of relocations pointing to themselves. With r347429 this can cause many sections to receive the same hash (usually zero) as a result of a section's hash being xor'ed with itself. This patch causes the COFF and ELF linkers to avoid this problem by adding the hash of the relocated section instead of xor'ing it. On my machine this causes the regressing test case provided by Mozilla to terminate in 2m41s. Differential Revision: https://reviews.llvm.org/D56955 llvm-svn: 351898
* 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
* Fix typos throughout the license files that somehow I and my reviewersChandler Carruth2019-01-211-1/+1
| | | | | | | | | | | all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended `legacy` anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. llvm-svn: 351731
* Tentative fix for r351701 and gcc 6.2 build on ubuntuSerge Guelton2019-01-211-2/+3
| | | | llvm-svn: 351728
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-19206-822/+618
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Install new LLVM license structure and new developer policy.Chandler Carruth2019-01-191-20/+236
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This installs the new developer policy and moves all of the license files across all LLVM projects in the monorepo to the new license structure. The remaining projects will be moved independently. Note that I've left odd formatting and other idiosyncracies of the legacy license structure text alone to make the diff easier to read. Critically, note that we do not in any case *remove* the old license notice or terms, as that remains necessary until we finish the relicensing process. I've updated a few license files that refer to the LLVM license to instead simply refer generically to whatever license the LLVM project is under, basically trying to minimize confusion. This is really the culmination of so many people. Chris led the community discussions, drafted the policy update and organized the multi-year string of meeting between lawyers across the community to figure out the strategy. Numerous lawyers at companies in the community spent their time figuring out initial answers, and then the Foundation's lawyer Heather Meeker has done *so* much to help refine and get us ready here. I could keep going on, but I just want to make sure everyone realizes what a huge community effort this has been from the begining. Differential Revision: https://reviews.llvm.org/D56897 llvm-svn: 351631
* Use llvm_canonicalize_cmake_booleans for LLVM_LIBXML2_ENABLED [lld]Nico Weber2019-01-193-5/+7
| | | | | | | | | | | | r291284 added a nice mechanism to consistently pass CMake on/off toggles to lit. This change uses it for LLVM_LIBXML2_ENABLED too (which was added around the same time and doesn't use the new system yet). No intended behavior change. Differential Revision: https://reviews.llvm.org/D56912 llvm-svn: 351614
* [lld] Use range-based llvm::sortMandeep Singh Grang2019-01-181-1/+1
| | | | llvm-svn: 351612
* [WebAssembly] Fix windows compiler warning by using explicit 64bit shift. NFC.Sam Clegg2019-01-172-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D56874 llvm-svn: 351488
* [WebAssembly] Changed objdump output to offsets instead of indices.Wouter van Oortmerssen2019-01-171-3/+3
| | | | | | | | | | | | Summary: This is to accommodate this change: https://reviews.llvm.org/D56684 Reviewers: sbc100 Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D56687 llvm-svn: 351462
* [WebAssembly] Merge producers sectionThomas Lively2019-01-173-2/+51
| | | | llvm-svn: 351412
* Revert "[WebAssembly] Merge producers section"Thomas Lively2019-01-173-50/+2
| | | | | | | This reverts commit 71eaf61c6c121c8c3bcaf3490557e92cf81599cb. One of the lld tests was breaking, so revert this change until it is fixed. llvm-svn: 351409
* [WebAssembly] Merge producers sectionThomas Lively2019-01-163-2/+50
| | | | | | | | | | Reviewers: sbc100, aheejin, dschuff Subscribers: jgravelle-google, sunfish, llvm-commits Differential Revision: https://reviews.llvm.org/D56807 llvm-svn: 351400
* [ELF][X86_64] Fix corrupted LD -> LE optimization for TLS without PLTPeter Wu2019-01-162-10/+119
| | | | | | | | | | | | | | | | | | | | 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-162-1/+45
| | | | | | | | | | | | | | | | | | 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-166-5/+99
| | | | | | | | | | | | | | | | | 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
* Bump the trunk version to 9.0.0svnHans Wennborg2019-01-162-42/+9
| | | | llvm-svn: 351320
* [WebAssembly] Store section alignment as a power of 2Sam Clegg2019-01-169-21/+21
| | | | | | | | | | | This change bumps for version number of the wasm object file metadata. See https://github.com/WebAssembly/tool-conventions/pull/92 Differential Revision: https://reviews.llvm.org/D56762 llvm-svn: 351287
* Do not emit a corrupt symbol table entry for .rela_iplt_{start,end}.Rui Ueyama2019-01-154-7/+35
| | | | | | | | | | | | | 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
* Update year in license filesHans Wennborg2019-01-151-1/+1
| | | | | | | In last year's update (D48219) it was suggested that the release manager might want to do this, so here we go. llvm-svn: 351194
* [ELF][AArch64] Add missing PLT relocations to isStaticLinkTimeConstantPeter Smith2019-01-152-3/+43
| | | | | | | | | | | | | 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
* lld-link: Spelling fixes in comments and minor style tweaksNico Weber2019-01-143-9/+12
| | | | | | | | | | | | | | Changes a few things I noticed while reading this code. - fix a few typos in comments - remove two `auto` uses where the type wasn't clear to me - add comment saying that two sequential checks for `if (SparseChunks[SectionNumber] == PendingComdat)` are intentional - name two parameters No behavior change. Differential Revision: https://reviews.llvm.org/D56677 llvm-svn: 351101
* lld/include/lld/Core/TODO.txtNico Weber2019-01-145-36/+18
| | | | | | | | | | | - fix minor grammar stuff (I'm not a native speaker either, but it's hopefully a net improvement) - mention that lld/coff is used in production - update AArch64, ARM to production quality - remove lld/include/lld/Core/TODO.txt which looks outdated Differential Revision: https://reviews.llvm.org/D56600 llvm-svn: 351030
* Add a release note about MSP430 support.Rui Ueyama2019-01-111-0/+2
| | | | llvm-svn: 350975
* Fix unchecked Error introduced in r350956Alexandre Ganea2019-01-111-1/+3
| | | | llvm-svn: 350968
* [LLD][COFF] Support /ignore:4099. Support /ignore with comma-separated ↵Alexandre Ganea2019-01-116-15/+49
| | | | | | | | arguments. Differential Revision: https://reviews.llvm.org/D56392 llvm-svn: 350956
* 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-102-1/+4
| | | | 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
* [ELF] Fix ARM and Thumb V7PILongThunk overflow behavior.Peter Smith2019-01-103-4/+84
| | | | | | | | | | | | | | | | | | When the range between the source and target of a V7PILongThunk exceeded an int32 we would trigger a relocation out of range error for the R_ARM_MOVT_PREL or R_ARM_THM_MOVT_PREL relocation. This case can happen when linking the linux kernel as it is loaded above 0xf0000000. There are two parts to the fix. - Remove the overflow check for R_ARM_MOVT_PREL or R_ARM_THM_MOVT_PREL. The ELF for the ARM Architecture document defines these relocations as having no overflow checking so the check was spurious. - Use int64_t for the offset calculation, in line with similar thunks so that PC + (S - P) < 32-bits. This results in less surprising disassembly. Differential Revision: https://reviews.llvm.org/D56396 llvm-svn: 350836
OpenPOWER on IntegriCloud