summaryrefslogtreecommitdiffstats
path: root/lld/test/ELF
Commit message (Collapse)AuthorAgeFilesLines
...
* Re-submit r367649: Improve raw_ostream so that you can "write" colors using ↵Rui Ueyama2019-08-071-2/+2
| | | | | | | | | operator<< The original patch broke buildbots, perhaps because it changed the default setting whether colors are enabled or not. llvm-svn: 368131
* [ELF][PPC] Don't relax ifunc toc-indirect accesses to toc-relativeFangrui Song2019-08-061-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PR42759. ``` // If ifunc is taken address in -fPIC code, it may have a toc entry .section .toc,"aw",@progbits .quad ifunc // ifunc may be defined as STT_GNU_IFUNC in another object file .type ifunc, %gnu_indirect_function ``` If ifunc is non-preemptable (e.g. when linking an executable), the toc entry will be relocated by R_PPC64_IRELATIVE. R_*_IRELATIVE represents the symbolic value of a non-preemptable ifunc (not associated with a canonical PLT) in a writable location. It has an unknown value at link time, so we cannot apply toc-indirect to toc-relative relaxation. Reviewed By: luporl, sfertile Differential Revision: https://reviews.llvm.org/D65755 llvm-svn: 368057
* [ELF][ARM] Fix /DISCARD/ of section with .ARM.exidx sectionPeter Smith2019-08-061-0/+37
| | | | | | | | | | | | | | | | | | The combineEhSections runs, by design, before processSectionCommands so that input exception sections like .ARM.exidx and .eh_frame are not assigned to OutputSections. Unfortunately if /DISCARD/ removes InputSections that have associated .ARM.exidx sections without discarding the .ARM.exidx synthetic section then we will end up crashing when trying to sort the InputSections in ascending address order. We fix this by filtering out the sections that have been discarded prior to processing the InputSections in finalizeContents(). fixes pr42890 Differential Revision: https://reviews.llvm.org/D65759 llvm-svn: 368041
* [ELF] Make binding (weak or non-weak) logic consistent for Undefined and ↵Fangrui Song2019-08-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SharedSymbol This is a case missed by D64136. If %t1.o has a weak reference on foo, and %t2.so has a non-weak reference on foo: ``` 0. ld.lld %t1.o %t2.so # ok; STB_WEAK; accepted since D64136 1. ld.lld %t2.so %t1.o # undefined symbol: foo; STB_GLOBAL 2. gold %t1.o %t2.so # ok; STB_WEAK 3. gold %t2.so %t1.o # undefined reference to 'foo'; STB_GLOBAL 4. ld.bfd %t1.o %t2.so # undefined reference to `foo'; STB_WEAK 5. ld.bfd %t2.so %t1.o # undefined reference to `foo'; STB_WEAK ``` It can be argued that in both cases, the binding of the undefined foo should be set to STB_WEAK, because the binding should not be affected by referenced from shared objects. --allow-shlib-undefined doesn't suppress errors (3,4,5), but -shared or --noinhibit-exec allows ld.bfd/gold to produce a binary: ``` 3. gold -shared %t2.so %t1.o # ok; STB_GLOBAL 4. ld.bfd -shared %t2.so %t1.o # ok; STB_WEAK 5. ld.bfd -shared %t1.o %t1.o # ok; STB_WEAK ``` If %t2.so has DT_NEEDED entries, ld.bfd will load them (lld/gold don't have the behavior). If one of the DSO defines foo and it is in the link-time search path (e.g. DT_NEEDED entry is an absolute path, via -rpath=, via -rpath-link=, etc), `ld.bfd %t1.o %t2.so` and `ld.bfd %t1.o %t2.so` will not error. In this patch, we make Undefined and SharedSymbol share the same binding computing logic. Case 1 will be allowed: ``` 0. ld.lld %t1.o %t2.so # ok; STB_WEAK; accepted since D64136 1. ld.lld %t2.so %t1.o # ok; STB_WEAK; changed by this patch ``` In the future, we can explore the option that turns both (0,1) into errors if --no-allow-shlib-undefined (default when linking an executable) is in action. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D65584 llvm-svn: 368038
* [ELF][test] Reorganize some tls-*.s testsFangrui Song2019-08-0514-245/+176
| | | | | | | | | | | | | | | | | | | | | Some tls-*.s tests do not test generic TLS behavior but rather are x86 specific. Rename them to i386-*.s or x86-64-*.s Delete tls-static.s: covered by tls-opt.s Delete tls-opt-no-plt.s: add --implicit-check-not=.plt to x86-64-tls-gdie.s to cover it Rename tls-dynamic-i686.s to i386-tls-dynamic.s Rename tls-i686.s to i386-tls-le.s Rename tls-opt-i686.s to i386-tls-opt.s Rename tls-opt-iele-i686-nopic.s to i386-tls-opt-iele-nopic.s Rename tls-dynamic.s to x86-64-tls-dynamic.s . IE should be split off in the future. Rename tls-error.s to x86-64-reloc-tpoff32-error.s Rename tls-opt-gdie.s to x86-64-tls-gdie.s Rename tls-opt-x86_64-noplt.s to x86-64-tls-opt-noplt.s Rename tls-opt-local.s => x86-64-tls-ie-opt-local.s . It can be merged with x86-64-tls-ie-local.s in the future. llvm-svn: 367877
* [ELF] Consistently prioritize non-* wildcards overs "*" in version scriptsFangrui Song2019-08-053-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We prioritize non-* wildcards overs VER_NDX_LOCAL/VER_NDX_GLOBAL "*". This patch generalizes the rule to "*" of other versions and thus fixes PR40176. I don't feel strongly about this GNU linkers' behavior but the generalization simplifies code. Delete `config->defaultSymbolVersion` which was used to special case VER_NDX_LOCAL/VER_NDX_GLOBAL "*". In `SymbolTable::scanVersionScript`, custom versions are handled the same way as VER_NDX_LOCAL/VER_NDX_GLOBAL. So merge `config->versionScript{Locals,Globals}` into `config->versionDefinitions`. Overall this seems to simplify the code. In `SymbolTable::assign{Exact,Wildcard}Versions`, `sym->verdefIndex == config->defaultSymbolVersion` is changed to `verdefIndex == UINT32_C(-1)`. This allows us to give duplicate assignment diagnostics for `{ global: foo; };` `V1 { global: foo; };` In test/linkerscript/version-script.s: vs_index of an undefined symbol changes from 0 to 1. This doesn't matter (arguably 1 is better because the binding is STB_GLOBAL) because vs_index of an undefined symbol is ignored. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D65716 llvm-svn: 367869
* [ELF][test] Delete redundant version-script-*.s testsFangrui Song2019-08-046-92/+3
| | | | | | | | Delete version-script-missing.s: it is covered by version-script-noundef.s Delete version-script-anonymous-local.s: it is covered by version-script-{glob,weak}.s etc Delete version-script-no-warn{,2}.s: add --fatal-warnings to some version-script.s commands instead llvm-svn: 367778
* [ELF] Move R_*_IRELATIVE from .rel[a].plt to .rel[a].dyn unless ↵Fangrui Song2019-08-0316-50/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --pack-dyn-relocs=android[+relr] An R_*_IRELATIVE represents the address of a STT_GNU_IFUNC symbol (redirected at runtime) which is non-preemptable and is not associated with a canonical PLT (associated with a symbol with a section index of SHN_UNDEF but a non-zero st_value). .rel[a].plt [DT_JMPREL, DT_JMPREL+DT_JMPRELSZ) contains relocations that can be lazily resolved. R_*_IRELATIVE are always eagerly resolved, so conceptually they do not belong to .rela.plt. "iplt" is mostly a misnomer. glibc powerpc and powerpc64 do not resolve R_*_IRELATIVE if they are in .rela.plt. // a.o - synthesized PLT call stub has an R_*_IRELATIVE void ifunc(); int main() { ifunc(); } // b.o static void real() {} asm (".type ifunc, %gnu_indirect_function"); void *ifunc() { return &real; } The lld-linked executable crashes. ld.bfd places R_*_IRELATIVE in .rela.dyn and the executable works. glibc i386, x86_64, and aarch64 have logic (glibc/sysdeps/*/dl-machine.h:elf_machine_lazy_rel) to eagerly resolve R_*_IRELATIVE in .rel[a].plt so the lld-linked executable works. Move R_*_IRELATIVE from .rel[a].plt to .rel[a].dyn to fix the crashes on glibc powerpc/powerpc64. This also helps simplifying ifunc implementation in FreeBSD rtld-elf powerpc64. If --pack-dyn-relocs=android[+relr] is specified, the Android packed dynamic relocation format is used for .rela.dyn. We cannot name in.relaIplt ".rela.dyn" because the output section will have mixed formats. This can be improved in the future. Reviewed By: pcc Differential Revision: https://reviews.llvm.org/D65651 llvm-svn: 367745
* Revert r367649: Improve raw_ostream so that you can "write" colors using ↵Rui Ueyama2019-08-021-2/+2
| | | | | | | | operator<< This reverts commit r367649 in an attempt to unbreak Windows bots. llvm-svn: 367658
* Improve raw_ostream so that you can "write" colors using operator<<Rui Ueyama2019-08-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. raw_ostream supports ANSI colors so that you can write messages to the termina with colors. Previously, in order to change and reset color, you had to call `changeColor` and `resetColor` functions, respectively. So, if you print out "error: " in red, for example, you had to do something like this: OS.changeColor(raw_ostream::RED); OS << "error: "; OS.resetColor(); With this patch, you can write the same code as follows: OS << raw_ostream::RED << "error: " << raw_ostream::RESET; 2. Add a boolean flag to raw_ostream so that you can disable colored output. If you disable colors, changeColor, operator<<(Color), resetColor and other color-related functions have no effect. Most LLVM tools automatically prints out messages using colors, and you can disable it by passing a flag such as `--disable-colors`. This new flag makes it easy to write code that works that way. Differential Revision: https://reviews.llvm.org/D65564 llvm-svn: 367649
* [ELF] Add -z separate-code and pad the last page of last PF_X PT_LOAD with ↵Fangrui Song2019-08-0114-60/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | traps only if -z separate-code is specified This patch 1) adds -z separate-code and -z noseparate-code (default). 2) changes the condition that the last page of last PF_X PT_LOAD is padded with trap instructions. Current condition (after D33630): if there is no `SECTIONS` commands. After this change: if -z separate-code is specified. -z separate-code was introduced to ld.bfd in 2018, to place the text segment in its own pages. There is no overlap in pages between an executable segment and a non-executable segment: 1) RX cannot load initial contents from R or RW(or non-SHF_ALLOC). 2) R and RW(or non-SHF_ALLOC) cannot load initial contents from RX. lld's current status: - Between R and RX: in `Writer<ELFT>::fixSectionAlignments()`, the start of a segment is always aligned to maxPageSize, so the initial contents loaded by R and RX do not overlap. I plan to allow overlaps in D64906 if -z noseparate-code is in effect. - Between RX and RW(or non-SHF_ALLOC if RW doesn't exist): we currently unconditionally pad the last page to commonPageSize (defaults to 4096 on all targets we support). This patch will make it effective only if -z separate-code is specified. -z separate-code is a dubious feature that intends to reduce the number of ROP gadgets (which is actually ineffective because attackers can find plenty of gadgets in the text segment, no need to find gadgets in non-code regions). With the overlapping PT_LOAD technique D64906, -z noseparate-code removes two more alignments at segment boundaries than -z separate-code. This saves at most defaultCommonPageSize*2 bytes, which are significant on targets with large defaultCommonPageSize (AArch64/MIPS/PPC: 65536). Issues/feedback on alignment at segment boundaries to help understand the implication: * binutils PR24490 (the situation on ld.bfd is worse because they have two R-- on both sides of R-E so more alignments.) * In binutils, the 2018-02-27 commit "ld: Add --enable-separate-code" made -z separate-code the default on Linux. https://github.com/richfelker/musl-cross-make/commit/d969dea983a2cc54a1e0308a0cdeb6c3307e4bfa In musl-cross-make, binutils is configured with --disable-separate-code to address size regressions caused by -z separate-code. (lld actually has the same issue, which I plan to fix in a future patch. The ld.bfd x86 status is worse because they default to max-page-size=0x200000). * https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237676 people want smaller code size. This patch will remove one alignment boundary. * Stef O'Rear: I'm opposed to any kind of page alignment at the text/rodata line (having a partial page of text aliased as rodata and vice versa has no demonstrable harm, and I actually care about small systems). So, make -z noseparate-code the default. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64903 llvm-svn: 367537
* [ELF] With --vs-diagnostics, print a separate message for each location of a ↵Igor Kudrin2019-08-011-2/+3
| | | | | | | | | | | | | duplicate symbol. We extract and print the source location in the message header so that Visual Studio is able to parse it and jump there. As duplicate symbols are defined in several locations, it is more convenient to have separate error messages, which allows a user to easily access all the locations. Differential Revision: https://reviews.llvm.org/D65213 llvm-svn: 367536
* [ELF][X86] Improve testsFangrui Song2019-08-019-201/+192
| | | | | | | | | | | | * Add --no-show-raw-insn to llvm-objdump -d tests * When linking an executable with %t.so, the path %t.so will be recorded in the DT_NEEDED entry if %t.so doesn't have DT_SONAME. .dynstr will have varying lengths on different systems. Add -soname so that the string in .dynstr is of fixed length to make tests more robust. * Rename i386-tls-initial-exec-local.s to i386-tls-ie-local.s * Refactor tls-initial-exec-local.s to x86-64-tls-ie-local.s llvm-svn: 367533
* [ELF] Fix finding locations in messages for undefined hidden symbols.Igor Kudrin2019-08-011-0/+42
| | | | | | | | | | | | Previously, when `--vs-diagnostics` was used, the linker printed something like hidden(undef.s): error: undefined hidden symbol: foo >>> referenced by undef.s:15 Differential Revision: https://reviews.llvm.org/D65499 llvm-svn: 367515
* [ELF][MIPS] Improve testsFangrui Song2019-07-2529-466/+466
| | | | | | | | | | * Add --no-show-raw-insn to llvm-objdump -d tests * When linking an executable with %t.so, the path %t.so will be recorded in the DT_NEEDED entry if %t.so doesn't have DT_SONAME. .dynstr will have varying lengths on different systems. Add -soname to make tests more robust. llvm-svn: 366988
* [LLD] Do not print additional newlines after reaching error limitAlexander Richardson2019-07-241-0/+24
| | | | | | | | | | | | | | | | | | | | Summary: This could previously happen if errors that are emitted after reaching the error limit. In that case, the flag inside the newline() function will be set to true which causes the next call to print a newline even though the actual message will be discarded. Reviewers: ruiu, grimar, MaskRay, espindola Reviewed By: ruiu Subscribers: emaste, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65198 llvm-svn: 366944
* ld.lld: Demangle symbols from archives in diagnosticsNico Weber2019-07-231-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | This ports r366573 from COFF to ELF. There are now to toString(Archive::Symbol), one doing MSVC demangling in COFF and one doing Itanium demangling in ELF, so rename these two to toCOFFString() and to toELFString() to not get a duplicate symbol. Nothing ever passes a raw Archive::Symbol to CHECK(), so these not being part of the normal toString() machinery seems ok. There are two code paths in the ELF linker that emits this type of diagnostic: 1. The "normal" one in InputFiles.cpp. This is covered by the tweaked test. 2. An additional one that's only used for libcalls if there's at least one bitcode in the link, and if the libcall symbol is lazy, and lazily loaded from an archive (i.e. not from a lazy .o file). (This code path was added in r339301.) Since all libcall names so far are C symbols and never mangled, the change there is not observable and hence not covered by tests. Differential Revision: https://reviews.llvm.org/D65095 llvm-svn: 366836
* [ARM][test] Improve testsFangrui Song2019-07-2246-253/+249
| | | | | | | Delete trailing 2>&1 that is not piped to another command. Add --no-show-raw-insn to objdump -d commands. llvm-svn: 366676
* [ELF] Support explicitly overriding relocation model in LTOPetr Hosek2019-07-201-0/+9
| | | | | | | | lld currently selects the relocation model automatically depending on the link flags specified, but in some cases it'd be useful to allow explicitly overriding the relocation model using a flag. llvm-svn: 366644
* [ELF][test] Fix aarch64-condb-reloc.sFangrui Song2019-07-191-1/+1
| | | | llvm-svn: 366534
* [ELF][AArch64] Improve some aarch64-*.s testsFangrui Song2019-07-1913-244/+188
| | | | | | | | | * Delete aarch64-tls-static.s: it is covered by aarch64-tlsdesc.c * Add --no-show-raw-insn to llvm-objdump -d tests * When linking an executable with %t.so, the path %t.so will be recorded in the DT_NEEDED entry if %t.so doesn't have DT_SONAME. The DT_NEEDED has varying lengths on different systems. Add -soname to make tests more robust. This issue will become outstanding if we allow overlapping PT_LOAD (D64930). llvm-svn: 366532
* ELF: Add support for remaining R_AARCH64_MOVW* relocations.Peter Collingbourne2019-07-182-0/+107
| | | | | | Differential Revision: https://reviews.llvm.org/D64685 llvm-svn: 366466
* ELF: Simplify test. NFCI.Peter Collingbourne2019-07-182-10/+6
| | | | | | | | | | Avoid splitting the test into multiple files and use zero for the value of the symbol with addends at relocations so that it's clear what value is being used at relocations. Differential Revision: https://reviews.llvm.org/D64684 llvm-svn: 366463
* ELF: Allow forward references to linked sections.Peter Collingbourne2019-07-181-0/+23
| | | | | | | | | | | It's possible to create IR that uses !associated to refer to a global that appears later in the module, which can result in these types of forward references being generated. Unfortunately our assembler does not currently accept the resulting .s so I needed to use yaml2obj to test this. Differential Revision: https://reviews.llvm.org/D64880 llvm-svn: 366460
* [ELF][PPC] Delete ppc64-dynamic-relocations.sFangrui Song2019-07-181-50/+0
| | | | | | I forgot to delete it in r366424. llvm-svn: 366445
* [ELF][PPC] Refactor some ppc64 testsFangrui Song2019-07-189-619/+307
| | | | | | | | Merge ppc64-dynamic-relocations.s into ppc64-plt-stub.s Add ppc64-tls-ie.s: covers ppc64-initial-exec-tls.s and ppc64-tls-ie-le.s Add ppc64-tls-gd.s: covers ppc64-general-dynamic-tls.s, ppc64-gd-to-ie.s, ppc64-tls-gd-le.s, and ppc64-tls-gd-le-small.s llvm-svn: 366424
* [lld] Fix vs-diagnostics-version-script test. NFC.Chris Jackson2019-07-181-5/+2
| | | | | | Removed unnecessary llvm-mc call. llvm-svn: 366418
* Fixup r366333 (require x86 in test)Diana Picus2019-07-181-0/+1
| | | | | | Seems to be required for the other added tests too. llvm-svn: 366416
* [ELF][test] Merge/rename some basic*.s testsFangrui Song2019-07-183-239/+40
| | | | | | | | | | basic64be.s is a big-endian powerpc64 test that just duplicates what basic-ppc64.s does. Extend basic-ppc64.s to add big-endian tests. Delete basic64be.s Rename basic32.s to basic-i386.s llvm-svn: 366401
* [lld] Add Visual Studio compatible diagnosticsChris Jackson2019-07-178-0/+215
| | | | | | | | | | | | Summary: Add a --vs-diagnostics flag that alters the format of diagnostic output to enable source hyperlinks in Visual Studio. Differential Revision: https://reviews.llvm.org/D58484 Reviewed by: ruiu llvm-svn: 366333
* [NFC][test] Fix for riscv tests.Puyan Lotfi2019-07-164-16/+16
| | | | | | Following tests need updating for: https://reviews.llvm.org/D55277 llvm-svn: 366183
* [ELF] Fix variable names in comments after VariableName -> variableName changeFangrui Song2019-07-163-9/+9
| | | | | | Also fix some typos. llvm-svn: 366181
* [mips] Simplify test case. NFCSimon Atanasyan2019-07-111-13/+5
| | | | | | | | Before rL295040 the linker just crashed when a GOT relocation (R_MIPS_GOT16) comes from a merge section. To ensure that this bug still fixed it's enough to check that the linker does not crash and create GOT entries. llvm-svn: 365834
* [ELF] Handle non-glob patterns before glob patterns in version scripts & fix ↵Fangrui Song2019-07-112-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a corner case of --dynamic-list This fixes PR38549, which is silently accepted by ld.bfd. This seems correct because it makes sense to let non-glob patterns take precedence over glob patterns. lld issues an error because `assignWildcardVersion(ver, VER_NDX_LOCAL);` is processed before `assignExactVersion(ver, v.id, v.name);`. Move all assignWildcardVersion() calls after assignExactVersion() calls to fix this. Also, move handleDynamicList() to the bottom. computeBinding() called by includeInDynsym() has this cryptic rule: if (versionId == VER_NDX_LOCAL && isDefined() && !isPreemptible) return STB_LOCAL; Before the change: * foo's version is set to VER_NDX_LOCAL due to `local: *` * handleDynamicList() is called - foo.computeBinding() is STB_LOCAL - foo.includeInDynsym() is false - foo.isPreemptible is not set (wrong) * foo's version is set to V1 After the change: * foo's version is set to VER_NDX_LOCAL due to `local: *` * foo's version is set to V1 * handleDynamicList() is called - foo.computeBinding() is STB_GLOBAL - foo.includeInDynsym() is true - foo.isPreemptible is set (correct) Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64550 llvm-svn: 365760
* [ELF] Warn rather than error when duplicate version assignments occurFangrui Song2019-07-112-6/+31
| | | | | | | | | | | | | | | | | | | | | | In lvm2, libdevmapper.so is linked with a version script with duplicate version assignments: DM_1_02_138 { global: ... dm_bitset_parse_list; ... }; DM_1_02_129 { global: ... dm_bitset_parse_list; ... }; ld.bfd silently accepts this while gold issues a warning. We currently error, thus inhibit producing the executable. Change the error to warning to allow this case, and improve the message. There are some cases where ld.bfd error `anonymous version tag cannot be combined with other version tags` but we just warn. It is probably OK for now. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D64549 llvm-svn: 365759
* Revert "[ELF] Update test case due to llvm r365618"Nikola Prica2019-07-101-7/+13
| | | | | | | | Reverting du to reverting r365618 This reverts commit b1e76d1d41c2303f70b53e352bdefbff2a2a9d37. llvm-svn: 365686
* ELF: Add support for R_AARCH64_ADR_PREL_PG_HI21_NC relocation.Peter Collingbourne2019-07-102-0/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D64456 llvm-svn: 365662
* [LLD][ELF] - Linkerscript: fix FILL() expressions handling.George Rimar2019-07-102-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | D64130 introduced a bug described in the following message: https://reviews.llvm.org/D64130#1571560 The problem can happen with the following script: SECTIONS { .out : { ... FILL(0x10101010) *(.aaa) ... } The current code tries to read (0x10101010) as an expression and does not break when meets *, what results in a script parsing error. In this patch, I verify that FILL command's expression always wrapped in (). And at the same time =<fillexp> expression can be both wrapped or unwrapped. I checked it matches to bfd/gold. Differential revision: https://reviews.llvm.org/D64476 llvm-svn: 365635
* [ELF] Update test case due to llvm r365618Nikola Prica2019-07-101-13/+7
| | | | llvm-svn: 365619
* [ELF][test] Rename tail-merge-string-align2.s to merge-string-align2.sFangrui Song2019-07-091-0/+0
| | | | | | | | | | This test was added by D64200/r365139 to check we don't merge SHF_MERGE|SHF_STRINGS sections with different alignments (that wastes space and can make MergeTailAlignment::Builder out of sync). It has nothing to do with tail merge (-O2), so rename it. llvm-svn: 365442
* Let unaliased Args track which Alias they were created from, and use that in ↵Nico Weber2019-07-091-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Arg::getAsString() for diagnostics With this, `clang-cl /source-charset:utf-16 test.cc` now prints `invalid value 'utf-16' in '/source-charset:utf-16'` instead of `invalid value 'utf-16' in '-finput-charset=utf-16'` before, and several other clang-cl flags produce much less confusing output as well. Fixes PR29106. Since an arg and its alias can have different arg types (joined vs not) and different values (because of AliasArgs<>), I chose to give the Alias its own Arg object. For convenience, I just store the alias directly in the unaliased arg – there aren't many arg objects at runtime, so that seems ok. Finally, I changed Arg::getAsString() to use the alias's representation if it's present – that function was already documented as being the suitable function for diagnostics, and most callers already used it for diagnostics. Implementation-wise, Arg::accept() previously used to parse things as the unaliased option. The core of that switch is now extracted into a new function acceptInternal() which parses as the _aliased_ option, and the previously-intermingled unaliasing is now done as an explicit step afterwards. (This also changes one place in lld that didn't use getAsString() for diagnostics, so that that one place now also prints the flag as the user wrote it, not as it looks after it went through unaliasing.) Differential Revision: https://reviews.llvm.org/D64253 llvm-svn: 365413
* [lld] Use -o /dev/null in test when output is not needed.Sam Clegg2019-07-081-1/+1
| | | | | | Fix for feedback nit from rL364998 llvm-svn: 365310
* lld, llvm-dlltool, llvm-lib: Use getAsString() instead of getSpelling() for ↵Nico Weber2019-07-051-2/+2
| | | | | | | | | | | | | | | 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][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
* [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
OpenPOWER on IntegriCloud