- Feb 01, 2017
-
-
George Rimar authored
llvm-svn: 293751
-
George Rimar authored
Accidentally lost the commit title and message, will recommit. llvm-svn: 293750
-
George Rimar authored
llvm-svn: 293749
-
George Rimar authored
This is alternative to D28857 which was incorrect. One of linux scripts contains: vvar_start = . - 2 * (1 << 12); vvar_page = vvar_start; vvar_vsyscall_gtod_data = vvar_page + 128; Previously we did not mark first expression as non-absolute, though it contains location counter. And LLD failed with error: relocation R_X86_64_PC32 cannot refer to absolute symbol This patch should fix the issue, and opens road for doing the same for other operators (though not clear if that is needed). Differential revision: https://reviews.llvm.org/D29332 llvm-svn: 293748
-
- Jan 31, 2017
-
-
Rui Ueyama authored
Previously, we were printing out something like this for sections/symbols with alignment 16 0000000000201000 0000000000000182 10 .data which I think confusing. I think printing it in decimal is better. Differential Revision: https://reviews.llvm.org/D29258 llvm-svn: 293685
-
Rui Ueyama authored
It is not clear what we should do when overflow occurs for these relocations because the relocations are not an official part of the i386 psABI. But checking for overflow is generally a good to do and is consistent with other relocations such as R_X86_64_8. llvm-svn: 293683
-
George Rimar authored
Our reporting for that case was just like: ld.lld: error: do not know how to handle relocation 'R_386_PC8' (23) It did not give any information about error location. Patch adds filename to error. Differential revision: https://reviews.llvm.org/D29282 llvm-svn: 293640
-
Michal Gorny authored
Add the CMake bits necessary to run lld tests (and unittests) when building stand-alone. The code is based on the equivalent code in clang, and includes: 1. checking for Python, searching for lit and necessary LLVM test tools (FileCount and not), 2. building LLVM test tools (FileCount and not) from LLVM sources if they are not installed, 3. building gtest libraries from LLVM sources, 4. adjusting dependencies so that test targets depend only on those LLVM targets that are available for a particular variant of stand-alone build. With this patch, I am able to successfully run 1002 (+10 unsupported) lit tests on Gentoo using installed LLVM. Differential Revision: https://reviews.llvm.org/D28750 llvm-svn: 293630
-
Eugene Leviant authored
Differential revision: https://reviews.llvm.org/D29278 llvm-svn: 293613
-
George Rimar authored
Linux kernel linkerscript contains additional semicolon (last line): .apicdrivers : AT(ADDR(.apicdrivers) - LOAD_OFFSET) { __apicdrivers = .; *(.apicdrivers); I checked that both gold and bfd are able to parse something like: .text : { ;;*(.text);;S = 0;; } } Patch do the same. Differential revision: https://reviews.llvm.org/D29276 llvm-svn: 293612
-
Rafael Espindola authored
It currently depends on the fact that we don't concatenate merge sections with the same name but different properties. llvm-svn: 293583
-
- Jan 30, 2017
-
-
Peter Collingbourne authored
llvm-svn: 293529
-
Peter Collingbourne authored
If no bss sections appear after the relro segment, the loader will round the r/w segment size to the target's page size. Align the relro size in the same way to ensure that it does not extend past the end of the program's own memory region. Differential Revision: https://reviews.llvm.org/D29242 llvm-svn: 293519
-
George Rimar authored
ld.bfd showed error on previous inputs, result values were larger than 8/16 bits, though ld.gold accepted them. ABI says "The R_386_16, and R_386_8 relocations truncate the computed value to 16-bits and 8-bits respectively". Patch changes inputs to have result calculated values of relocations to fit 8 and 16 bits. That can be used for implementation of more strict checks, like bfd do. Differential revision: https://reviews.llvm.org/D29270 llvm-svn: 293479
-
Rui Ueyama authored
llvm-svn: 293452
-
- Jan 29, 2017
-
-
Rui Ueyama authored
llvm-svn: 293409
-
- Jan 28, 2017
-
-
Rafael Espindola authored
llvm-svn: 293390
-
Rafael Espindola authored
The symbols _end, end, _etext, etext, _edata, edata and __ehdr_start refer to positions in the file and are therefore not absolute. Making them absolute was on unfortunate cargo cult of what bfd was doing. Changing the symbols allows for pc relocations to them to be resolved, which should fix the wine build. llvm-svn: 293385
-
Sylvestre Ledru authored
llvm-svn: 293380
-
Rui Ueyama authored
This reverts commit r293283 because it broke MSVC build. llvm-svn: 293352
-
- Jan 27, 2017
-
-
Rafael Espindola authored
[ELF] Fixed formatting. NFC and [ELF] Bypass section type check Differential revision: https://reviews.llvm.org/D28761 They do the opposite of what was asked for in the code review. llvm-svn: 293320
-
Rafael Espindola authored
Now reportUndefined only has to look at Config->UnresolvedSymbols and the symbol. getUnresolvedSymbolOption does all the hard work of mapping options like -shared and -z defs to one of the UnresolvedPolicy enum entries. The critical fix is that now "-z defs --warn-unresolved-symbols" only warns. llvm-svn: 293290
-
Peter Smith authored
Thunks are now implemented by redirecting the relocation to the symbol S, to a symbol TS in a Thunk. The Thunk will transfer control to S. This has the following implications: - All the side-effects of Thunks happen within createThunks() - Thunks are no longer stored in InputSections and Symbols no longer need to hold a pointer to a Thunk - The synthetic Thunk sections need to be merged into OutputSections This implementation is almost a direct conversion of the existing Thunks with the following exceptions: - Mips LA25 Thunks are placed before the InputSection that defines the symbol that needs a Thunk. - All ARM Thunks are placed at the end of the OutputSection of the first caller to the Thunk. Range extension Thunks are not supported yet so it is optimistically assumed that all Thunks can be reused. Differential Revision: https://reviews.llvm.org/D29129 llvm-svn: 293283
-
Eugene Leviant authored
llvm-svn: 293278
-
Eugene Leviant authored
Differential revision: https://reviews.llvm.org/D28761 llvm-svn: 293276
-
Simon Dardis authored
Currently LLVM can only generate PIC code for MIPS64 with the N64 as it uses the idiom "isPositionIndependent() || IsABI_N64()" throughout the MIPS backend. r293164 changed this, causing test failures for LLD. This patch changes the tests minimally to preserve existing test coverage and one case where the test was "right" in the wrong circumstance. Reviewers: atanasyan Differential Revision: https://reviews.llvm.org/D29194 llvm-svn: 293275
-
- Jan 26, 2017
-
-
Rafael Espindola authored
Should fix a few freebsd packages with dtrace. llvm-svn: 293177
-
Rui Ueyama authored
llvm-svn: 293144
-
Rui Ueyama authored
Negative flags are still bit flags, so I think "not flag" is a very good name. llvm-svn: 293143
-
Rui Ueyama authored
llvm-svn: 293142
-
Rui Ueyama authored
llvm-svn: 293141
-
Davide Italiano authored
Patch by Dmitry Mikulin. PR: 31735 Differential Revision: https://reviews.llvm.org/D29150 llvm-svn: 293139
-
Peter Collingbourne authored
Now we never append a number to the file name for task ID 0. This is similar to r293132 in the gold plugin. llvm-svn: 293138
-
Rui Ueyama authored
llvm-svn: 293130
-
Bob Haarman authored
Summary: MSVC allows linker options to be specified in source code. One of these is the /INCLUDE directive, which specifies that a symbol must be added to the symbol table, even if it otherwise wouldn't be. Existing tests cover the case where the linker is given an object file with an /INCLUDE directive, but we also need to cover the case where /INCLUDE is specified in a bitcode file (as would happen when using LTO). This new test covers that case. Reviewers: pcc, ruiu Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D29096 llvm-svn: 293107
-
- Jan 25, 2017
-
-
Adrian McCarthy authored
This eliminates one overload on the term Raw. Differential Revision: https://reviews.llvm.org/D29098 llvm-svn: 293104
-
Rui Ueyama authored
llvm-svn: 293100
-
Rui Ueyama authored
llvm-svn: 293096
-
Rui Ueyama authored
llvm-svn: 293095
-
Rafael Espindola authored
It now uses the same infrastructure as symbol versions. This fixes us creating a dynamic relocation without a corresponding dynamic symbol. This also means that unlike gold and bfd we keep a STB_LOCAL in the static symbol table. It seems an odd feature to offer precise control over what is in a symbol table that is not used by the dynamic linker. We can bring this back if needed, but it would probably be better to just have --discard option that tells the linker to keep in the static symbol table only what is in the dynamic one. Should fix the eog build. llvm-svn: 293093
-