summaryrefslogtreecommitdiffstats
path: root/lld/test
Commit message (Collapse)AuthorAgeFilesLines
...
* [lld][WebAssembly] Fix __start/__stop symbols when combining input segmentsSam Clegg2019-07-082-11/+11
| | | | | | | | | | | | We should be generating one __start/__stop pair per output segment not per input segment. The test wasn't catching this because it was only linking a single object file. Fixes PR41565 Differential Revision: https://reviews.llvm.org/D64148 llvm-svn: 365308
* [lld][WebAssembly] Fix typo in error messageSam Clegg2019-07-081-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D64315 llvm-svn: 365304
* lld, llvm-dlltool, llvm-lib: Use getAsString() instead of getSpelling() for ↵Nico Weber2019-07-052-7/+7
| | | | | | | | | | | | | | | printing unknown args Since OPT_UNKNOWN args never have any values and consist only of spelling (and are never aliased), this doesn't make any difference in practice, but it's more consistent with Arg's guidance to use getAsString() for diagnostics, and it matches what clang does. Also tweak two tests to use an unknown option that contains '=' for additional coverage while here. (The new tests pass fine with the old code too though.) llvm-svn: 365200
* [LLD][ELF] - Update a test after LLVM change.George Rimar2019-07-051-2/+2
| | | | | | Error reporting changed in r365183 llvm-svn: 365184
* lld-link: Make /debugtype: option work betterNico Weber2019-07-051-3/+8
| | | | | | | | | | | | | | | | | | | - The code tried to pass false to split()'s KeepEmpty parameter, but instead passed it to MaxSplit. As a result, it would never split on commas. This has been broken since the flag was added in r278056. - The code used getSpelling() for getting the argument's values, but getSpelling() always returns the `/debugtype:` prefix without any values. So if any /debugtype: flag was passed, it always resulted in an "unknown option:" warning. (The warning code then used the correct getValue() for printing the invalid option, so the warning looked kind of like it made sense.) This regressed in r342894. Slightly improve the test coverage of this feature (but since I don't know what this flag actually does, there's still no test for the correct semantics), and add a comment to getSpelling() explaining what it does. llvm-svn: 365182
* [LLD][ELF] - Linkerscript: add a support for expressions for section's fillingGeorge Rimar2019-07-042-3/+23
| | | | | | | | | | | | | | | | | | | Imagine the script: .section: { ... } = FILL_EXPR LLD assumes that FILL_EXPR is a number, and does not allow it to be an expression. Though that is allowed by specification: https://sourceware.org/binutils/docs-2.32/ld/Output-Section-Fill.html This patch adds a support for cases when FILL_EXPR is simple math expression. Fixes https://bugs.llvm.org/show_bug.cgi?id=42482. Differential revision: https://reviews.llvm.org/D64130 llvm-svn: 365143
* [ELF] Allow placing non-string SHF_MERGE sections with different alignments ↵Fangrui Song2019-07-044-48/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into the same MergeSyntheticSection The difference from D63432/r365015 is that this patch does not place SHF_STRINGS sections with different alignments into the same MergeSyntheticSection. Doing that would: (1) create unnecessary padding and thus waste space. Add a test tail-merge-string-align2.s to check no extra padding is created. (2) make some input sections unaligned when tail merge (-O2) is enabled. The alignment of MergeTailAlignment::Builder was out of sync in D63432. MOVAPS on such unaligned strings can raise SIGSEGV. This should fix PR42289: the Linux kernel has a use case that input files have .rodata.cst32 sections with different alignments. The expectation (and what ld.bfd and gold do) is that in the -r link, there is only one .rodata.cst32 (SHF_MERGE sections with different alignments can be combined), but lld currently creates one for each different alignment. The current merging strategy: 1) Group SHF_MERGE sections by (name, sh_flags, sh_entsize and sh_addralign). Merging is performed among a group, even if -O0 is specified. 2) Create one output section for each group. This is a special case in addInputSec(). This patch changes 1) to: 1) Group SHF_MERGE sections by (name, sh_flags, sh_entsize). Merging is performed among a group, even if -O0 is specified. We will thus create just one .rodata.cst32 . This also improves merging efficiency when sections with the same name but different alignments are combined. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D64200 llvm-svn: 365139
* [ELF] Fix weak-undef-shared.s after r365129Fangrui Song2019-07-041-0/+1
| | | | llvm-svn: 365131
* [ELF] resolveUndefined: ignore undefined symbols in SharedFile for Undefined ↵Fangrui Song2019-07-042-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and SharedSymbol If %t1.o has a weak reference on foo, and %t2.so has a non-weak reference on foo: `ld.lld %t1.o %t2.so -o %t` We incorrectly set the binding of the undefined foo to STB_GLOBAL. Fix this by ignoring undefined symbols in a SharedFile for Undefined and SharedSymbol. This fixes the binding of pthread_once when the program links against both librt.so and libpthread.so ``` a.o: STB_WEAK reference to pthread_once librt.so: STB_GLOBAL reference to pthread_once # should be ignored libstdc++.so: STB_WEAK reference to pthread_once # should be ignored libgcc_s.so.1: STB_WEAK reference to pthread_once # should be ignored ``` The STB_GLOBAL pthread_once issue (not fixed by D63974) can cause a link error when the result DSO is used to link another DSO with -z defs if -lpthread is not specified. (libstdc++.so.6 not having a dependency on libpthread.so is a really nasty hack...) We happened to create a weak undef before D63974 because libgcc_s.so.1 was linked the last and it changed the binding again to weak. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64136 llvm-svn: 365129
* [WebAssembly] Add option to emit passive segmentsThomas Lively2019-07-032-30/+206
| | | | | | | | | | | | | | | | | | | | | | | Summary: Adds `--passive-segments` and `--active-segments` flags to control what kind of segments are emitted. For now the default is always to emit active segments so this is not a breaking change, but in the future the default will be changed to passive segments when shared memory is requested and active segments otherwise. When passive segments are emitted, corresponding memory.init and data.drop instructions are emitted in a `__wasm_init_memory` function that is automatically called at the beginning of `__wasm_call_ctors`. Reviewers: sbc100, aheejin, dschuff Subscribers: azakai, dschuff, jgravelle-google, sunfish, jfb, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59343 llvm-svn: 365088
* [ELF][RISCV] Error on R_RISCV_PCREL_LO12_[IS] that point to absolute symbolsFangrui Song2019-07-031-0/+7
| | | | | | | | | | | | | | The referenced symbol is expected to point to an R_RISCV_*_HI20 relocation. An absolute symbol has no associated section, therefore there cannot be a matching R_RISCV_*_HI20. This fixes the crash reported by PR42038. For reference, ld.bfd errors: (.init+0x4): dangerous relocation: %pcrel_lo missing matching %pcrel_hi Differential Revision: https://reviews.llvm.org/D63273 llvm-svn: 365049
* Revert D63432 "[ELF] Allow placing SHF_MERGE sections with different ↵Fangrui Song2019-07-033-84/+48
| | | | | | | | | | | | | | | | alignments into the same MergeSyntheticSection" This reverts r365015. David Zarzycki reported this change broke stage2 and stage3 tests. The root cause is still not very clear, but I guess some SHF_MERGE sections with the same name have different alignments. They were not merged before but were merged after r365015. Something that assumes address uniqueness of such mergeable data caused the bug. llvm-svn: 365048
* [ELF][RISCV] Allow R_RISCV_ADD in relocateNonAlloc()Fangrui Song2019-07-031-0/+6
| | | | | | | | | | | | gcc may generate .debug_info/.debug_aranges/.debug_line/etc that are relocated by R_RISCV_ADD*/R_RISCV_SUB* pairs. Allow R_RISCV_ADD in non-SHF_ALLOC section to fix link errors like: ld.lld: error: print.c:(.debug_frame+0x60): has non-ABS relocation R_RISCV_ADD64 against symbol '.L0 ' Differential Revision: https://reviews.llvm.org/D63259 llvm-svn: 365035
* [ELF] Allow placing SHF_MERGE sections with different alignments into the ↵Fangrui Song2019-07-033-48/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | same MergeSyntheticSection This should fix PR42289: the Linux kernel has a use case that input files have .rodata.cst32 sections with different alignments. The expectation (and what ld.bfd and gold do) is that in the -r link, there is only one .rodata.cst32 (SHF_MERGE sections with different alignments can be combined), but lld currently creates one for each different alignment. The current merging strategy: 1) Group SHF_MERGE sections by (name, sh_flags, sh_entsize and sh_addralign). String merging is performed among a group, even if -O0 is specified. 2) Create one output section for each group. This is a special case in addInputSec(). This patch changes 1) to: 1) Group SHF_MERGE sections by (name, sh_flags, sh_entsize). String merging is performed among a group, even if -O0 is specified. We will thus create just one .rodata.cst32 . This also improves merging efficiency when sections with the same name but different alignments are combined. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63432 llvm-svn: 365015
* Revert r364999: [lld] Use -o /dev/null in test when output is not needed.Rui Ueyama2019-07-031-1/+1
| | | | | | | This reverts commit r364999 as it broke a build. Looks like `%t.archive.o` is used two lines below where it was created. llvm-svn: 365001
* [lld] Use -o /dev/null in test when output is not needed.Sam Clegg2019-07-031-1/+1
| | | | | | Feedback nit from rL364998 llvm-svn: 364999
* [ELF] Error on archive with missing indexSam Clegg2019-07-032-1/+14
| | | | | | | | | | | | This matches the wasm lld and GNU ld behavior. The ELF linker has special handling for bitcode archives but if that doesn't kick in we probably want to error out rather than silently ignore the library. Differential Revision: https://reviews.llvm.org/D63781 llvm-svn: 364998
* [ELF][RISCV] Support RISC-V in getBitcodeMachineKindKito Cheng2019-07-032-0/+20
| | | | | | | | | | | Add Triple::riscv64 and Triple::riscv32 to getBitcodeMachineKind for get right e_machine during LTO. Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D52165 llvm-svn: 364996
* [ELF] Only allow the binding of SharedSymbol to change for the first undef refFangrui Song2019-07-022-17/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PR42442 t.o has a STB_GLOBAL undef ref to f t2.so has a STB_WEAK undef ref to f t1.so defines f ld.lld t.o t1.so t2.so currently sets the binding of `f` to STB_WEAK. This is not correct because there exists a STB_GLOBAL undef ref from a regular object. The problem is that resolveUndefined() doesn't check if the undef ref is seen for the first time: if (isShared() || isLazy() || (isUndefined() && Other.Binding != STB_WEAK)) Binding = Other.Binding; The isShared() condition should be `isShared() && !Referenced` where Referenced is set to true after an undef ref is seen. In practice, when linking a pthread program with glibc: // a.o #include <pthread.h> pthread_mutex_t mu = PTHREAD_MUTEX_INITIALIZER; int main() { pthread_mutex_unlock(&mu); } {clang,gcc} -fuse-ld=lld a.o -lpthread # libpthread.so is linked before libgcc_s.so.1 The weak undef pthread_mutex_unlock in libgcc_s.so.1 makes the result weak, which diverges from GNU linkers where STB_DEFAULT is used: 23: 0000000000000000 0 FUNC WEAK DEFAULT UND pthread_mutex_lock (Note, if -pthread is used instead, libpthread.so will be linked **after** libgcc_s.so.1 . lld sets the binding to the expected STB_GLOBAL) Similar linking sequences (ld.lld t.o t1.so t2.so) appear to be used by Go, which cause a build error https://github.com/golang/go/issues/31912. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D63974 llvm-svn: 364913
* [ELF][RISCV] Support GD/LD/IE/LE TLS modelsFangrui Song2019-07-014-0/+337
| | | | | | | | | | | | RISC-V psABI doesn't specify TLS relaxation. It can be handled the same way as we handle ARM TLS. RISC-V TLS is even simpler because GD/LD use the same relocation type. Reviewed By: jrtc27, ruiu Differential Revision: https://reviews.llvm.org/D63220 llvm-svn: 364813
* [ELF][RISCV] Support PLT, GOT, copy and relative relocationsFangrui Song2019-07-016-0/+247
| | | | | | | | | | | | | | | | | | | | * Handle initial relocation types: R_RISCV_CALL_PLT and R_RISCV_GOT_HI20. * Produce dynamic relocation types: R_RISCV_COPY, R_RISCV_RELATIVE, R_RISCV_JUMP_SLOT. * Define SymbolRel as R_RISCV_{32,64} * Generate PLT header: it is used by lazy binding PLT in glibc. * R_RISCV_CALL is changed from R_PC to R_PC_PLT. If the target symbol is preemptable, this will suppress an unnecessary "canonical PLT". This behavior is different from ld.bfd but it is agreed the current lld behavior is favored. I have received positive responses from the binutils maintainer that the ABI/binutils implementation can be improved, see: https://github.com/riscv/riscv-elf-psabi-doc/issues/98 https://sourceware.org/bugzilla/show_bug.cgi?id=24685 Many -no-pie/-pie/-shared programs linked against musl or glibc should work with this patch. Reviewed By: jrtc27 Differential Revision: https://reviews.llvm.org/D63076 llvm-svn: 364812
* [COFF] Fix .rsrc sections with differing permissionsMartin Storsjo2019-06-282-0/+5
| | | | | | | | | | | GNU windres, and MS cvtres (unless the /readonly option is passed) produce read-write .rsrc sections, when creating resource object files. This caused the sections to not be added to the precreated RsrcSec, and therefore not be added to the data directory. Differential Revision: https://reviews.llvm.org/D63837 llvm-svn: 364660
* [ELF] Do not produce DT_JMPREL and DT_PLTGOT if .rela.plt is empty.Igor Kudrin2019-06-281-0/+44
| | | | | | | | | | | | | If .rela.plt is mentioned in a linker script, it might be preserved even if it is empty. In that case, LLD created DT_JMPREL and DT_PLTGOT dynamic tags. When the tags exist, a dynamic loader writes values into reserved slots in .got.plt to support lazy symbol resolution. The problem is that, in fact, the linker has not reserved that space, and the writing may occur into the memory allocated for something else. Differential Revision: https://reviews.llvm.org/D63869 llvm-svn: 364639
* [LLD][ELF] - Replace invalid-e_shnum.s with YAML based version.George Rimar2019-06-273-3/+15
| | | | | | | | | The previous version used a precompiled binary. After this patch, we have no more precompiled binaries in LLD ELF test suite :) llvm-svn: 364529
* [wasm-ld] Add __global_base symbol to mark the value of --global-baseGuanzhong Chen2019-06-261-0/+71
| | | | | | | | | | | | | | | | | | | | | | Summary: This is needed for address sanitizer on Emscripten. As everything in memory starts at the value passed to --global-base, everything before that can be used as shadow memory. This symbol is added so that the library for the ASan runtime can know where the shadow memory ends and real memory begins. This is split from D63742. Reviewers: tlively, aheejin, sbc100 Subscribers: sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63833 llvm-svn: 364467
* [LLD][COFF] Case insensitive compares for /nodefaultlibAlexandre Ganea2019-06-261-0/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D63775 llvm-svn: 364438
* Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the ↵Fangrui Song2019-06-269-67/+167
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sections were discarded This restores r361830 "[ELF] Error on relocations to STT_SECTION symbols if the sections were discarded" and dependent commits (r362218, r362497) which were reverted by r364321, with a fix of a --gdb-index issue. .rela.debug_ranges contains relocations of range list entries: // start address of a range list entry // old: 0; after r361830: 0 00000000000033a0 R_X86_64_64 .text._ZN2v88internal7Isolate7factoryEv + 0 // end address of a range list entry // old: 0xe; after r361830: 0 00000000000033a8 R_X86_64_64 .text._ZN2v88internal7Isolate7factoryEv + e If both start and end addresses of a range list entry resolve to 0, DWARFDebugRangeList::isEndOfListEntry() will return true, then the .debug_range decoding loop will terminate prematurely: while (true) { decode StartAddress decode EndAddress if (Entry.isEndOfListEntry()) // prematurely break; Entries.push_back(Entry); } In lld/ELF/SyntheticSections.cpp, readAddressAreas() will read incomplete address ranges and the resulting .gdb_index will be incomplete. For files that gdb hasn't loaded their debug info, gdb uses .gdb_index to map addresses to CUs. The absent entries make gdb fail to symbolize some addresses. To address this issue, we simply allow relocations to undefined symbols in DWARF.cpp:findAux() and let RelocationResolver resolve them. This patch should fix: [1] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190603/659848.html [2] https://bugs.chromium.org/p/chromium/issues/detail?id=978067 llvm-svn: 364391
* [lld/WebAssembly] Slightly nicer error message for malformed input filesKeno Fischer2019-06-261-0/+0
| | | | | | | | | | | | | | | | | | | Summary: Before: ``` wasm-ld: error: Relocations not in offset order ``` After ``` wasm-ld: error: While processing `libjulia.so`: Relocations not in offset order ``` At least this way you get to find out which input file is malformed. Reviewers: sbc100 Differential Revision: https://reviews.llvm.org/D63694 llvm-svn: 364368
* [WebAssembly] Fix list of relocations with addends in lldKeno Fischer2019-06-262-1/+21
| | | | | | | | | | | | | Summary: The list of relocations with addend in lld was missing `R_WASM_MEMORY_ADDR_REL_SLEB`, causing `wasm-ld` to generate corrupted output. This fixes that problem and while we're at it pulls the list of such relocations into the Wasm.h header, to avoid duplicating it in multiple places. Reviewers: sbc100 Differential Revision: https://reviews.llvm.org/D63696 llvm-svn: 364367
* [WebAssembly] Error on archives without a symbol indexSam Clegg2019-06-251-0/+13
| | | | | | | | | | | | | | | | | | This is fairly common with wasm since GNU ar (most likely the system ar) doesn't support the wasm object format so user who don't override AR will end up with archives without an index. We don't want to silently ignore this issue. In the future we could choose to instead behave like the ELF backend and read the symbols from each object file in the archive if they are all of the same type. However, error'ing out seem like a conservative approach for now. Fixes: PR42376 Differential Revision: https://reviews.llvm.org/D63739 llvm-svn: 364338
* Revert r362743 "Revert "Revert "Reland D61583 [ELF] Error on relocations to ↵Hans Wennborg2019-06-257-114/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | STT_SECTION symbols if the sections were discarded""" (In effect, reverting "[ELF] Error on relocations to STT_SECTION symbols if the sections were discarded".) It caused debug info problems in LibreOffice [1] and Chromium/V8 [2]. Reverting until those can be fixed. It also reverts r362497 "STT_SECTION symbol should be defined" on .eh_frame, .debug*, .zdebug* and .gcc_except_table" which was landed as a follow-up to the above. > With -r or --emit-relocs, we warn `STT_SECTION symbol should be defined` > on relocations to discarded section symbol. This was added as an error > in rLLD319404, but was not so effective before D61583 (it turned the > error to a warning). > > Relocations from .eh_frame .debug* .zdebug* .gcc_except_table to > discarded .text are very common and somewhat expected. Don't warn/error > on them. As a reference, ld.bfd has a similar logic in > _bfd_elf_default_action_discarded() to allow these cases. > > Delete invalid-undef-section-symbol.test because what it intended to > check is now covered by the updated comdat-discarded-reloc.s > > Delete relocatable-eh-frame.s because we allow relocations from > .eh_frame as a special case now. And finally it reverts r362218 "[ELF] Replace a dead test in getSymVA() with assert()" as that also depended on the main change reverted here. > Symbols relative to discarded comdat sections are Undefined instead of > Defined now (after D59649 and D61583). The `== &InputSection::Discarded` > test becomes dead. I cannot find a test related to this behavior. [1] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190603/659848.html [2] https://bugs.chromium.org/p/chromium/issues/detail?id=978067 llvm-svn: 364321
* Port r363962 to COFF: Deduplicate undefined symbol diagnosticsNico Weber2019-06-251-0/+47
| | | | | | | | | | | | | | | | | | lld/coff already deduplicated undefined symbols on a TU level: It would group all references to a symbol from a single TU. This makes it so that references from all TUs to a single symbol are grouped together. Since lld/coff almost did what I thought it did already, the patch is much smaller than the elf version. The only not local change is that getSymbolLocations() now returns a vector<string> instead of a string, so that the undefined symbol reporting code can know how many references to a symbol exist in a given TU. Fixes PR42260 for lld/coff. Differential Revision: https://reviews.llvm.org/D63646 llvm-svn: 364285
* Fix an issue that common symbols are not internalized under some condition.Rui Ueyama2019-06-251-0/+21
| | | | | | | | | | | | | | | | | | | | r360841 introduced CommonSymbol class. An unintended behavioral change introduced by that change was that common symbols are not internalized by LTO under some condition. This patch fixes that issue. The issue occurred under the following condition: 1. There exists a common symbol 2. At least one DSO is given to lld or -pie is used If the above conditions are met, Symbol::includeInDynsym() returned a wrong value for a common symbol. Fixes https://bugs.llvm.org/show_bug.cgi?id=41978 Differential Revision: https://reviews.llvm.org/D63752 llvm-svn: 364273
* [ELF][PPC][X86] Use [-2**(n-1), 2**n) to check overflows for R_PPC_ADDR16, ↵Fangrui Song2019-06-2420-108/+95
| | | | | | | | | | | | | | | | | | | | | R_PPC64_ADDR{16,32}, R_X86_64_{8,16} Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of `[-2**(n-1), 2**(n-1))` to check overflows. The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel. The new behavior is compatible with ld.bfd's complain_overflow_bitfield. The upper bound of the error message is not correct. Fix it as well. The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63690 llvm-svn: 364164
* lld/elf: Deduplicate undefined symbol diagnosticsNico Weber2019-06-202-1/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before: ``` ld.lld: error: undefined symbol: f() >>> referenced by test.cc:3 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(g()) ld.lld: error: undefined symbol: f() >>> referenced by test.cc:4 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(h()) ld.lld: error: undefined symbol: f() >>> referenced by test.cc:5 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(j()) ld.lld: error: undefined symbol: k() >>> referenced by test.cc:5 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(j()) ld.lld: error: undefined symbol: f() >>> referenced by test2.cc:2 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test2-07b391.o:(asdf()) clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` Now: ``` ld.lld: error: undefined symbol: f() >>> referenced by test.cc:3 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(g()) >>> referenced by test.cc:4 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(h()) >>> referenced by test.cc:5 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(j()) >>> referenced by test2.cc:2 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test2-6bdb24.o:(asdf()) ld.lld: error: undefined symbol: k() >>> referenced by test.cc:5 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(j()) clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` If there are more than 10 references to an undefined symbol, only the first 10 are printed. Fixes PR42260. Differential Revision: https://reviews.llvm.org/D63344 llvm-svn: 363962
* [ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for ↵Fangrui Song2019-06-206-73/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | absolute relocation types in writable sections Summary: Our rule to create R_*_RELATIVE for absolute relocation types were loose. D63121 made it stricter but it failed to create R_*_RELATIVE for R_ARM_TARGET1 and R_PPC64_TOC. rLLD363236 worked around that by reinstating the original behavior for ARM and PPC64. This patch is an attempt to simplify the logic. Note, in ld.bfd, R_ARM_TARGET2 --target2=abs also creates R_ARM_RELATIVE. This seems a very uncommon scenario (moreover, --target2=got-rel is the default), so I do not implement any logic related to it. Also, delete R_AARCH64_ABS32 from AArch64::getDynRel. We don't have working ILP32 support yet. Allowing it would create an incorrect R_AARCH64_RELATIVE. For MIPS, the (if SymbolRel, then RelativeRel) code is to keep its behavior unchanged. Note, in ppc64-abs64-dyn.s, R_PPC64_TOC gets an incorrect addend because computeAddend() doesn't compute the correct address. We seem to have the wrong behavior for a long time. The important thing seems that a dynamic relocation R_PPC64_TOC should not be created as the dynamic loader will error R_PPC64_TOC is not supported. Reviewers: atanasyan, grimar, peter.smith, ruiu, sfertile, espindola Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63383 llvm-svn: 363928
* [llvm-readobj] Match GNU output for DT_RPATH and DT_RUNPATH when dumping ↵Yuanfang Chen2019-06-193-4/+4
| | | | | | | | | | | | | | dynamic symbol table. Reviewers: jhenderson, grimar, MaskRay, rupprecht, espindola Subscribers: emaste, nemanjai, arichardson, kbarton, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63347 llvm-svn: 363868
* [PDB] Ignore .debug$S subsections with high bit setReid Kleckner2019-06-181-0/+14
| | | | | | | | Some versions of the Visual C++ 2015 runtime have line tables with the subsection kind of 0x800000F2. In cvinfo.h, 0x80000000 is documented to be DEBUG_S_IGNORE. This appears to implement the intended behavior. llvm-svn: 363724
* [Remarks] Extend -fsave-optimization-record to specify the formatFrancis Visoiu Mistrih2019-06-171-0/+3
| | | | | | | | | Use -fsave-optimization-record=<format> to specify a different format than the default, which is YAML. For now, only YAML is supported. llvm-svn: 363573
* [llvm-objdump] Use %08 instead of %016 to print leading addresses for 32-bit ↵Fangrui Song2019-06-175-16/+16
| | | | | | | | | | binaries Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D63398 llvm-svn: 363539
* [COFF] Strip section name suffix from mingw comdatsMartin Storsjo2019-06-141-0/+39
| | | | | | | | This is the second part of the fix for PR42217. Differential Revision: https://reviews.llvm.org/D63352 llvm-svn: 363457
* [COFF] Handle .eh_frame$symbol as associative comdat for MinGWMartin Storsjo2019-06-141-0/+37
| | | | | | | | | | | | | This matches how it is done for .xdata and .pdata already. On i386, the symbol name in the section name suffix does not contain the extra underscore prefix. This is one part of a fix for PR42217. Differential Revision: https://reviews.llvm.org/D63350 llvm-svn: 363456
* [MinGW] Support the --subsystem=val option in joined formMartin Storsjo2019-06-141-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D63250 llvm-svn: 363433
* [MinGW] Support the --{major,minor}-{os,subsystem}-version optionsMartin Storsjo2019-06-141-0/+14
| | | | | | | | This fixes PR42218. Differential Revision: https://reviews.llvm.org/D63249 llvm-svn: 363432
* [COFF] Allow setting subsystem versions while inferring the subsystem type ↵Martin Storsjo2019-06-142-0/+13
| | | | | | | | implicitly Differential Revision: https://reviews.llvm.org/D63248 llvm-svn: 363431
* Wrap a test to 80 columnsNico Weber2019-06-141-2/+2
| | | | llvm-svn: 363421
* [LLD][ELF] - Fix test case after r363401George Rimar2019-06-141-1/+1
| | | | llvm-svn: 363402
* [ELF] Don't emit dynamic relocations with weak undef in writable sectionsFangrui Song2019-06-141-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In processRelocAux(), our handling of 1) link-time constant and 2) weak undef is the same, so put them together to simplify the logic. This moves the weak undef code around. The result is that: in a writable section (or -z notext), we will no longer emit dynamic relocations for weak undefined symbols. The new behavior seems to match GNU linkers, and improves consistency with the case of a readonly section. The condition `!Config->Shared` was there probably because it is common for a -shared link not to specify full dependencies. Keep it now but we may revisit the decision in the future. gABI says: > The behavior of weak symbols in areas not specified by this document is > implementation defined. Weak symbols are intended primarily for use in > system software. Applications using weak symbols are unreliable since > changes in the runtime environment might cause the execution to fail. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63003 llvm-svn: 363399
* Revert r363395.George Rimar2019-06-141-1/+1
| | | | | | It will not work because of r363394. llvm-svn: 363398
* Add --undefined-glob which is an --undefined with wildcard pattern matchRui Ueyama2019-06-141-0/+58
| | | | | | | | | | | | | | | | | | | | | This patch adds new command line option `--undefined-glob` to lld. That option is a variant of `--undefined` but accepts wildcard patterns so that all symbols that match with a given pattern are handled as if they were given by `-u`. `-u foo` is to force resolve symbol foo if foo is not a defined symbol and there's a static archive that contains a definition of symbol foo. Now, you can specify a wildcard pattern as an argument for `--undefined-glob`. So, if you want to include all JNI symbols (which start with "Java_"), you can do that by passing `--undefined-glob "Java_*"` to the linker, for example. In this patch, I use the same glob pattern matcher as the version script processor is using, so it does not only support `*` but also `?` and `[...]`. Differential Revision: https://reviews.llvm.org/D63244 llvm-svn: 363396
OpenPOWER on IntegriCloud