- Aug 24, 2017
-
-
Simon Atanasyan authored
Currently LLD reads the R_MIPS_HI16's addends in the `computeMipsAddend` function, the R_MIPS_LO16's addends in both `computeMipsAddend` and `getImplicitAddend` functions. This patch moves reading all addends to the `getImplicitAddend` function. As a side effect it fixes a "paired" HI16/LO16 addend calculation if "LO16" part of a pair is not found. llvm-svn: 311711
-
Simon Atanasyan authored
llvm-svn: 311710
-
Rui Ueyama authored
llvm-svn: 311700
-
Rui Ueyama authored
llvm-svn: 311696
-
Rui Ueyama authored
Fixes https://bugs.llvm.org/show_bug.cgi?id=34311 llvm-svn: 311682
-
Rui Ueyama authored
Before this patch, lld printed out something like error: -O: number expected, but got After this patch, it prints out the same error message like this: error: -O: number expected, but got '' Fixes https://bugs.llvm.org/show_bug.cgi?id=34311 llvm-svn: 311681
-
- Aug 23, 2017
-
-
Sam Clegg authored
Also remove unused include of raw_ostream.h Differential Revision: https://reviews.llvm.org/D37048 llvm-svn: 311587
-
Petr Hosek authored
Currently, LLD checks whether there's enough space for headers by checking if headers fit below the address of the first allocated section. However, that's always thue if the binary doesn't start at zero which means that LLD always emits a segment for headers, even if no other sections belong to that segment. This is a problem in cases when linker script is being used with a non-zero start address when we don't want to make the headers visible by not leaving enough space for them. This pattern is common in embedded programming but doesn't work in LLD. This patch changes the behavior of LLD in case when linker script is being to match the behavior of BFD ld and gold, which is to only place headers into a segment when they're covered by some output section. Differential Revision: https://reviews.llvm.org/D36256 llvm-svn: 311586
-
George Rimar authored
Previously up to 3 errors were reported at once, with patch we always will report only one, just like in other linker code. Differential revision: https://reviews.llvm.org/D37015 llvm-svn: 311537
-
George Rimar authored
It was broken from begining, because visibility attributes were not applied properly to symbols before this patch. Differential revision: https://reviews.llvm.org/D36966 llvm-svn: 311536
-
George Rimar authored
Code suggested by Rui Ueyama in PR34238 comments. Previously LTO optimized away symbols referenced from linker script because did not see that them are used from regular objects. Patch adds such symbols as undefined earlier, before running LTO, what sets IsUsedInRegularObj for them and fixes the issue. Differential revision: https://reviews.llvm.org/D37009 llvm-svn: 311534
-
Martell Malone authored
llvm-svn: 311518
-
- Aug 22, 2017
-
-
Rui Ueyama authored
This reverts commit r311468 because it broke some CFI bots. llvm-svn: 311497
-
Rui Ueyama authored
Patch by Rafael Espíndola. This is PR34053. The implementation is a bit of a hack, given the precise location where IsPreemtible is set, it cannot be used from SymbolTable::handleAnonymousVersion. I could add another method to SymbolTable if you think that would be better. Differential Revision: https://reviews.llvm.org/D36499 llvm-svn: 311468
-
George Rimar authored
llvm-svn: 311449
-
George Rimar authored
This is PR33097. Previously when doing relocatable link, all IR symbols were absent in result object file. Patch makes external symbols to be exported. Differential revision: https://reviews.llvm.org/D36957 llvm-svn: 311431
-
Chandler Carruth authored
a std::move() isn't needed here as the object is a temporary. llvm-svn: 311430
-
Eric Beckmann authored
Summary: Now that the llvm-mt manifest merging libraries are complete, we may use them to merge manifests instead of needing to shell out to mt.exe. Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D36255 llvm-svn: 311424
-
- Aug 21, 2017
-
-
Sam Elliott authored
Summary: This change depends on https://reviews.llvm.org/D36054 and should be landed at the same time. Reviewers: anemet Reviewed By: anemet Subscribers: llvm-commits, emaste Differential Revision: https://reviews.llvm.org/D36950 llvm-svn: 311348
-
Zachary Turner authored
This adds support for dumping a summary of module symbols and CodeView debug chunks. This option prints a table for each module of all of the symbols that occurred in the module and the number of times it occurred and total byte size. Then at the end it prints the totals for the entire file. Additionally, this patch adds the -jmc (just my code) option, which suppresses modules which are from external libraries or linker imports, so that you can focus only on the object files and libraries that originate from your own source code. llvm-svn: 311338
-
James Henderson authored
hexdump is not part of the GNU coreutils, and so is not required to be able to build and test LLVM, according to the documentation. This change removes the dependency on hexdump from a lit test. Reviewers: grimar Differential Revision: https://reviews.llvm.org/D36958 llvm-svn: 311335
-
George Rimar authored
With fix: explicitly specify ouput format for hexdump tool call. Original commit message: [ELF] - Do not forget to fill last bytes of PT_LOADs with trap instructions. Previously last 4 bytes of executable loads were not filled with trap instructions, patch fixes this bug. Differential revision: https://reviews.llvm.org/D36262 llvm-svn: 311315
-
George Rimar authored
[ELF] - Revert r311310 "[ELF] - Do not forget to fill last bytes of PT_LOADs with trap instructions." It broke BB: http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/11792/steps/test_lld/logs/stdio llvm-svn: 311314
-
George Rimar authored
This is PR32942, previously threading was disabled because slowed down this testcase a lot. It was fixed in r311312. llvm-svn: 311313
-
George Rimar authored
[ELF] - Do not segfault when doing logical and/or operations on symbols that have no output sections. Previously we would crash on samples from testcase, because were trying to access zero pointer to output section. Differential revision: https://reviews.llvm.org/D36145 llvm-svn: 311311
-
George Rimar authored
Previously last 4 bytes of executable loads were not filled with trap instructions, patch fixes this bug. Differential revision: https://reviews.llvm.org/D36262 llvm-svn: 311310
-
- Aug 19, 2017
-
-
Rui Ueyama authored
I renamed corresponding classes in r309199 but forgot to rename enums at the moment. Rename them now to make them consistent. llvm-svn: 311214
-
- Aug 18, 2017
-
-
Ben Dunbobbin authored
Removed extraneous comment markers llvm-svn: 311169
-
- Aug 17, 2017
-
-
George Rimar authored
We would previously crash on next script: MEMORY { name : ORIGIN = .; } Patch fixes that. Differential revision: https://reviews.llvm.org/D36138 llvm-svn: 311073
-
Rui Ueyama authored
We had a lock to guard BAlloc from being used concurrently, but that is not very easy to understand. This patch replaces it with a std::unique_ptr. llvm-svn: 311056
-
- Aug 16, 2017
-
-
Davide Italiano authored
Also add a test. This fixes r310995 and PR34200. llvm-svn: 310998
-
George Rimar authored
Clang passes this options to linker. We should ignore them, anyways they are always enabled by default atm. Fixes https://bugs.llvm.org/show_bug.cgi?id=34200. llvm-svn: 310995
-
Martin Storsjö authored
When creating an import library from lld, the cases with Name != ExtName shouldn't end up as a weak alias, but as a real export of the new name, which is what actually is exported from the DLL. This restores the behaviour of renamed exports to what it was in 4.0. Differential Revision: https://reviews.llvm.org/D36634 llvm-svn: 310992
-
Martin Storsjö authored
Since SVN r303491 and r304573, LLD used the COFFImportLibrary functions from LLVM. These only had two names, Name and ExtName, which wasn't enough to convey all the details of stdcall functions. Stdcall functions got the wrong symbol name in the import library itself in r303491, which is why it was reverted in r304561. When re-landed and fixed in r304573 (after adding a test in r304572), the symbol name itself in the import library ended up right, but the name type of the import library entry was wrong. This had the effect that linking to the import library succeeded (contrary to in r303491, where linking to such an import library failed), but at runtime, the symbol wouldn't be found in the DLL (since the caller linked to the stdcall decorated name). Differential Revision: https://reviews.llvm.org/D36545 llvm-svn: 310989
-
- Aug 15, 2017
-
-
Zachary Turner authored
I'm explicitly ignoring the warning by casting to void instead of deleting the local assignment, because it's confusing to see a function that fails when its return value evaluates to true. But when you see that it's a std::error_code, it makes more sense. llvm-svn: 310965
-
Zachary Turner authored
Previously, our algorithm to compute a build id involved hashing the executable and storing that as the GUID in the CV Debug Record chunk, and setting the age to 1. This breaks down in one very obvious case: a user adds some newlines to a file, rebuilds, but changes nothing else. This causes new line information and new file checksums to get written to the PDB, meaning that the debug info is different, but the generated code would be the same, so we would write the same build over again with an age of 1. Anyone using a symbol cache would have a problem now, because the debugger would open the executable, look at the age and guid, find a matching PDB in the symbol cache and then load it. It would never copy the new PDB to the symbol cache. This patch implements the canonical Windows algorithm for updating a build id, which is to check the existing executable first, and re-use an existing GUID while bumping the age if it already exists. Differential Revision: https://reviews.llvm.org/D36758 llvm-svn: 310961
-
Rui Ueyama authored
GdbIndexSection doesn't need lazy finalization because when an instance of the class is created, we already know all debug info sections. We can initialize the instnace in the ctor. llvm-svn: 310931
-
Rui Ueyama authored
llvm-svn: 310930
-
Rui Ueyama authored
llvm-svn: 310929
-
Rui Ueyama authored
This function doesn't seem to add value to the symbol table as it is easy to write code without it. llvm-svn: 310925
-