summaryrefslogtreecommitdiffstats
path: root/lld/ELF
Commit message (Collapse)AuthorAgeFilesLines
...
* [ELF][RISCV] Assign st_shndx of __global_pointer$ to 1 if .sdata does not existFangrui Song2019-08-283-38/+9
| | | | | | | | | | | | | | | | | | | | | | | | This essentially reverts the code change of D63132 and switches to a simpler approach. In an executable/shared object, st_shndx of a symbol can be: 1) SHN_UNDEF: undefined symbol (or canonical PLT) 2) SHN_ABS: absolute symbol 3) any other value (usually a regular section index) represents a relative symbol. The actual value does not matter. Many ld.so (musl, all archs except MIPS of FreeBSD rtld-elf) even treat 2) and 3) the same. If .sdata does not exist, it does not matter what value/section __global_pointer$ has, as long as it is relative (otherwise there will be a pedantic lld error. See D63132). Just set the st_shndx arbitrarily to 1. Dummy st_shndx=1 may be used by __rela_iplt_start, linker-script-defined symbols outside a section, __dso_handle, etc. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D66798 llvm-svn: 370172
* [ELF][ARM] Allow PT_LOAD to have overlapping p_offset ranges on EM_ARMFangrui Song2019-08-271-1/+2
| | | | | | | | | | | | Port the D64906 technique to ARM. It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of an arm binary decreases by at most 12kb. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D66749 llvm-svn: 370049
* [ELF] EhFrameSection: postpone FDE liveness check to finalizeSectionsFangrui Song2019-08-264-32/+50
| | | | | | | | | | | | | | | EhFrameSection::addSection checks liveness of FDE early. This makes it infeasible to move combineEhSections() before ICF. Postpone the check to EhFrameSection::finalizeContents(). This is what ARMExidxSyntheticSection does and it will make a subsequent patch D66717 simpler. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D66727 llvm-svn: 369890
* [ELF] Make LinkerScript::assignAddresses iterativeFangrui Song2019-08-264-17/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PR42990. For `SECTIONS { b = a; . = 0xff00 + (a >> 8); a = .; }`, we currently set st_value(a)=0xff00 while st_value(b)=0xffff. The following call tree demonstrates the problem: ``` link<ELF64LE>(Args); Script->declareSymbols(); // insert a and b as absolute Defined Writer<ELFT>().run(); Script->processSectionCommands(); addSymbol(cmd); // a and b are re-inserted. LinkerScript::getSymbolValue // is lazily called by subsequent evaluation finalizeSections(); forEachRelSec(scanRelocations<ELFT>); processRelocAux // another problem PR42506, not affected by this patch finalizeAddressDependentContent(); // loop executed once script->assignAddresses(); // a = 0, b = 0xff00 script->assignAddresses(); // a = 0xff00, _end = 0xffff ``` We need another assignAddresses() to finalize the value of `a`. This patch 1) modifies assignAddress() to track the original section/value of each symbol and return a symbol whose section/value has changed. 2) moves the post-finalizeSections assignAddress() inside the loop of finalizeAddressDependentContent() and makes it iterative. Symbol assignment may not converge so we make a few attempts before bailing out. Note, assignAddresses() must be called at least twice. The penultimate call finalized section addresses while the last finalized symbol values. It is somewhat obscure and there was no comment. linkerscript/addr-zero.test tests this. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D66279 llvm-svn: 369889
* [ELF] Error if --strip-all and --emit-relocs are used togetherFangrui Song2019-08-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | --strip-all suppresses the creation of in.symtab This can cause a null pointer dereference in OutputSection::finalize() // --emit-relocs => copyRelocs is true if (!config->copyRelocs || (type != SHT_RELA && type != SHT_REL)) return; ... link = in.symTab->getParent()->sectionIndex; // in.symTab is null Let's just disallow the combination. In some cases the combination can cause GNU linkers to fail: * ld.bfd: final link failed: invalid operation * gold: internal error in set_no_output_symtab_entry, at ../../gold/object.h:1814 Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D66704 llvm-svn: 369878
* [ELF] Delete a redundant dyn_cast<InputSection>. NFCFangrui Song2019-08-251-6/+5
| | | | llvm-svn: 369868
* [ELF] Simplify with less_second. NFCFangrui Song2019-08-241-4/+1
| | | | llvm-svn: 369844
* [ELF] Make member function Writer<ELFT>::removeEmptyPTLoad non-member. NFCFangrui Song2019-08-241-3/+1
| | | | llvm-svn: 369838
* [ELF] Align the first section of a PT_LOAD even if its type is SHT_NOBITSFangrui Song2019-08-241-11/+12
| | | | | | | | | | | | | | | | | | | | | Reported at https://reviews.llvm.org/D64930#1642223 If the only section of a PT_LOAD is a SHT_NOBITS section (e.g. .bss), we may not align its sh_offset. p_offset of the PT_LOAD will be set to sh_offset, and we will get p_offset!=p_vaddr (mod p_align). If such executable is mapped by the Linux kernel, it will segfault. After D64906, this may happen the non-linker script case. The linker script case has had this issue for a long time. This was fixed by rL321657 (but the test linkerscript/nobits-offset.s failed to test a SHT_NOBITS section), but broken by rL345154. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D66658 llvm-svn: 369828
* [ELF] Mention contents of reproduce archive and add help description.Peter Smith2019-08-231-1/+1
| | | | | | | | | | | | Building on D60557 mention the name of the linker generated contents of the reproduce archive, response.txt and version.txt. Also write a shorter description in the ld.lld --help that is closer to the documentation. Differential Revision: https://reviews.llvm.org/D66641 llvm-svn: 369762
* Fight a bit against global initializers. NFC.Benjamin Kramer2019-08-221-2/+2
| | | | llvm-svn: 369695
* Reland D65242 "[ELF] More dynamic relocation packing""Fangrui Song2019-08-211-7/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixed a bug in r369488. When config->isRela is false, i->r_addend is not initialized (see encodeDynamicReloc). So we should check config->isRela before accessing r_addend: - if (j - i < 3 || i->r_addend) + if (j - i < 3 || (config->isRela && i->r_addend != 0)) Original description: Currently, with Android dynamic relocation packing, only relative relocations are grouped together. This patch implements similar packing for non-relative relocations. The implementation groups non-relative relocations with the same r_info and r_addend, if using RELA. By requiring a minimum group size of 3, this achieves smaller relocation sections. Building Android for an ARM32 device, I see the total size of /system/lib decrease by 392 KB. Grouping by r_info also allows the runtime dynamic linker to implement an 1-entry cache to reduce the number of symbol lookup required. With such 1-entry cache implemented on Android, I'm seeing 10% to 20% reduction in total time spent in runtime linker for several executables that I tested. As a simple correctness check, I've also built x86_64 Android and booted successfully. Differential Revision: https://reviews.llvm.org/D65242 Patch by Vic Yang llvm-svn: 369507
* Revert D65242 "[ELF] More dynamic relocation packing"Fangrui Song2019-08-211-66/+7
| | | | | | | | | This reverts r369488 and r369489. The change broke build bots: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-ubsan/builds/14511 http://lab.llvm.org:8011/builders/lld-x86_64-freebsd/builds/34407 llvm-svn: 369497
* [ELF] More dynamic relocation packingFangrui Song2019-08-211-7/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, with Android dynamic relocation packing, only relative relocations are grouped together. This patch implements similar packing for non-relative relocations. The implementation groups non-relative relocations with the same r_info and r_addend, if using RELA. By requiring a minimum group size of 3, this achieves smaller relocation sections. Building Android for an ARM32 device, I see the total size of /system/lib decrease by 392 KB. Grouping by r_info also allows the runtime dynamic linker to implement an 1-entry cache to reduce the number of symbol lookup required. With such 1-entry cache implemented on Android, I'm seeing 10% to 20% reduction in total time spent in runtime linker for several executables that I tested. As a simple correctness check, I've also built x86_64 Android and booted successfully. Differential Revision: https://reviews.llvm.org/D66491 Patch by Vic Yang! llvm-svn: 369488
* [ELF][PPC] Allow PT_LOAD to have overlapping p_offset ranges on EM_PPCFangrui Song2019-08-201-1/+1
| | | | | | | | Ported the D64906 technique to EM_PPC. Delete ppc-rela.s that is covered by ppc32-abs-pic.s llvm-svn: 369351
* [ELF][X86] Allow PT_LOAD to have overlapping p_offset ranges on EM_386Fangrui Song2019-08-201-2/+3
| | | | | | | | | | | | | | | | | | | | Ported the D64906 technique to EM_386. If `sh_addralign(.tdata) < sh_addralign(.tbss)`, we can potentially make `p_vaddr(PT_TLS)%p_align(PT_TLS) != 0`. ld.so that are known to have problems if p_vaddr%p_align!=0: * FreeBSD 13.0-CURRENT rtld-elf * glibc https://sourceware.org/bugzilla/show_bug.cgi?id=24606 New test i386-tls-vaddr-align.s checks our workaround makes p_vaddr%p_align = 0. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D65865 llvm-svn: 369347
* [ELF][AArch64] Allow PT_LOAD to have overlapping p_offset rangesFangrui Song2019-08-201-1/+2
| | | | | | | | | | | | | | | | | | | | | | Ported the D64906 technique to AArch64. It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of an aarch64 binary decreases by at most 192kb. If `sh_addralign(.tdata) < sh_addralign(.tbss)`, we can potentially make `p_vaddr(PT_TLS)%p_align(PT_TLS) != 0`. ld.so that are known to have problems if p_vaddr%p_align!=0: * musl<=1.1.22 * FreeBSD 13.0-CURRENT (and before) rtld-elf arm64 New test aarch64-tls-vaddr-align.s checks that our workaround makes p_vaddr%p_align = 0. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64930 llvm-svn: 369344
* [ELF][PPC] Allow PT_LOAD to have overlapping p_offset rangesFangrui Song2019-08-202-26/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change affects the non-linker script case (precisely, when the `SECTIONS` command is not used). It deletes 3 alignments at PT_LOAD boundaries for the default case: the size of a powerpc64 binary can be decreased by at most 192kb. The technique can be ported to other targets. Let me demonstrate the idea with a maxPageSize=65536 example: When assigning the address to the first output section of a new PT_LOAD, if the end p_vaddr of the previous PT_LOAD is 0x10020, we advance to the next multiple of maxPageSize: 0x20000. The new PT_LOAD will thus have p_vaddr=0x20000. Because p_offset and p_vaddr are congruent modulo maxPageSize, p_offset will be 0x20000, leaving a p_offset gap [0x10020, 0x20000) in the output. Alternatively, if we advance to 0x20020, the new PT_LOAD will have p_vaddr=0x20020. We can pick either 0x10020 or 0x20020 for p_offset! Obviously 0x10020 is the choice because it leaves no gap. At runtime, p_vaddr will be rounded down by pagesize (65536 if pagesize=maxPageSize). This PT_LOAD will load additional initial contents from p_offset ranges [0x10000,0x10020), which will also be loaded by the previous PT_LOAD. This is fine if -z noseparate-code is in effect or if we are not transiting between executable and non-executable segments. ld.bfd -z noseparate-code leverages this technique to keep output small. This patch implements the technique in lld, which is mostly effective on targets with large defaultMaxPageSize (AArch64/MIPS/PPC: 65536). The 3 removed alignments can save almost 3*65536 bytes. Two places that rely on p_vaddr%pagesize = 0 have to be updated. 1) We used to round p_memsz(PT_GNU_RELRO) up to commonPageSize (defaults to 4096 on all targets). Now p_vaddr%commonPageSize may be non-zero. The updated formula takes account of that factor. 2) Our TP offsets formulae are only correct if p_vaddr%p_align = 0. Fix them. See the updated comments in InputSection.cpp for details. On targets that we enable the technique (only PPC64 now), we can potentially make `p_vaddr(PT_TLS)%p_align(PT_TLS) != 0` if `sh_addralign(.tdata) < sh_addralign(.tbss)` This exposes many problems in ld.so implementations, especially the offsets of dynamic TLS blocks. Known issues: FreeBSD 13.0-CURRENT rtld-elf (i386/amd64/powerpc/arm64) glibc (HEAD) i386 and x86_64 https://sourceware.org/bugzilla/show_bug.cgi?id=24606 musl<=1.1.22 on TLS Variant I architectures (aarch64/powerpc64/...) So, force p_vaddr%p_align = 0 by rounding dot up to p_align(PT_TLS). The technique will be enabled (with updated tests) for other targets in subsequent patches. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64906 llvm-svn: 369343
* [ELF] Simplify processRelocAux and allow a corner-case errorFangrui Song2019-08-191-4/+0
| | | | | | | | | | | | | | | | After D66007/r369262, if the control flow reaches `if (sym.isUndefined())`, we know: * The relocation is not a link-time constant => symbol is preemptable => Undefined or SharedSymbol * Not an undef weak. * -no-pie. * The symbol type is neither STT_OBJECT nor STT_FUNC. ld.lld --export-dynamic --unresolved-symbols=ignore-all %t.o can satisfy these conditions. Delete the isUndefined() test so that we error `symbol '...' has no type`, because we don't know the type to make the decision to create copy relocation/canonical PLT. llvm-svn: 369271
* [ELF] Move (copy relocation/canonical PLT) before error checkingFangrui Song2019-08-191-59/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | In processRelocAux(), we handle errors before copy relocation/canonical PLT. This makes error checking a bit complex because we have to check for conditions that will be allowed by copy relocation/canonical PLT. Instead, move copy relocation/canonical PLT before error checking. This simplifies the previous clumsy error checking code `config->shared || (config->pie && expr == R_ABS && type != target->symbolicRel)` to the simple `config->isPic`. Some diagnostics can be reported in different ways. The code motion changes diagnostics for some contrived test cases: * copy-rel-pie-error.s -> copy-rel-pie2.s: It was rejected before but accepted now. ld.bfd also accepts the case. * copy-errors.s: "cannot preempt symbol" changes to "symbol 'bar' has no type" * got32{,x}-i386.s: the suggestion changes from "-fPIC or -Wl,-z,notext" to "-fPIE" * x86-64-dyn-rel-error5.s: one diagnostic changes for -pie case Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D66007 llvm-svn: 369262
* [ELF][Hexagon] Improve error message for unknown relocationsFangrui Song2019-08-191-3/+18
| | | | | | | | | | | | | | | | | | | | Like rLLD354040 Previously, for unknown relocation types, in -no-pie/-pie mode, we got something like: foo.o: unrecognized relocation ... In -shared mode: error: can't create dynamic relocation ... against symbol: yyy in readonly segment Delete the default case from Hexagon::getRelExpr and add the error there. We will get consistent error message like `error: unknown relocation (1024) against symbol foo` Reviewed By: sidneym Differential Revision: https://reviews.llvm.org/D66275 llvm-svn: 369260
* [lld][Hexagon] Add GOTREL relocations.Sid Manning2019-08-191-0/+11
| | | | | | | | Add GOTREL relocation support. (S + A - GOT) Differential Revision: https://reviews.llvm.org/D66260 llvm-svn: 369258
* [ELF] Replace local variable hasExportDynamic with config->exportDynamic. NFCFangrui Song2019-08-171-5/+2
| | | | llvm-svn: 369187
* [ELF][PPC] Fix getRelExpr for R_PPC64_REL16_HIFangrui Song2019-08-171-0/+1
| | | | | | | | | | | | Fixes https://github.com/ClangBuiltLinux/linux/issues/640 R_PPC64_REL16_HI was incorrectly computed as an R_ABS relocation. rLLD368964 made it a linker failure. Change it to use R_PC to fix the failures. Add ppc64-reloc-rel.s for these R_PPC64_REL* tests. llvm-svn: 369184
* [ELF][Hexagon] Replace R_HEXAGON_GOT with R_GOTPLTFangrui Song2019-08-164-8/+5
| | | | | | | | | | | R_GOTPLT is relative to .got.plt since D59594. Since R_HEXAGON_GOT relocations always have 0 r_addend, they can use R_GOTPLT instead. Reviewed By: sidneym Differential Revision: https://reviews.llvm.org/D66274 llvm-svn: 369128
* [lld][Hexagon]Support HEX_32 when building shared objectsSid Manning2019-08-161-0/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D66105 llvm-svn: 369121
* Fix lld on GCC 5.1 after the C++14 moveJF Bastien2019-08-151-26/+24
| | | | | | | | | | | | | | | | | | | | | | | Summary: libstdc++ in GCC 5.1 has some bugs. The move to C++14 in D66195 triggered one such bug caused by the new constexpr support in C++14, and the implementation doing SFINAE wrong with the comparator to std::stable_sort. Here's a small repro: https://godbolt.org/z/2QC3-n The fix is to inline the lambdas directly into the llvm::stable_sort call instead of erasing them through a std::function. The code is more readable as well. Reviewers: thakis, ruiu, espindola Subscribers: emaste, arichardson, MaskRay, jkorous, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66306 llvm-svn: 369023
* [ELF][AArch64] Improve error message for unknown relocationsFangrui Song2019-08-151-2/+24
| | | | | | | | | | | | | | | | | | | | Like rLLD354040. Previously, for unrecognized relocation types, in -no-pie/-pie mode, we got something like: foo.o: unrecognized relocation ... In -shared mode: error: can't create dynamic relocation ... against symbol: yyy in readonly segment Delete the default case from AArch64::getRelExpr and add the error there. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D66277 llvm-svn: 368983
* [ELF][PPC] Improve error message for unknown relocationsFangrui Song2019-08-152-4/+30
| | | | | | | | | | | | | | Like rLLD354040. Previously, for unrecognized relocation types, in -no-pie mode: foo.o: unrecognized reloc 256 In -pie/-shared mode: error: can't create dynamic relocation R_PPC_xxx against symbol: yyy in readonly segment llvm-svn: 368964
* [LLD] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-144-8/+8
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368936
* [ELF] --gdb-index: fix odd variable name cUs after r365730 and replace ↵Fangrui Song2019-08-141-7/+6
| | | | | | lower_bound with partition_point. NFC llvm-svn: 368845
* [ELF] Initialize 2 fields of Symbol in SymbolTable::insertFangrui Song2019-08-142-0/+6
| | | | | | | | | | | | | | | | | | | A new symbol is added to elf::symtab in 3 steps: 1) SymbolTable::insert creates a placeholder. 2) Symbol::mergeProperties 3) Symbol::replace Fields referenced by steps 2) and 3) should be initialized in SymbolTable::insert. `traced` and `referenced` were missed previously. This did not cause problems because compilers generated code that initialized them (bit fields) to 0. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D66130 llvm-svn: 368784
* [ELF] Don't special case symbolic relocations with 0 addend to ifunc in ↵Fangrui Song2019-08-133-48/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | writable locations Currently the following 3 relocation types do not trigger the creation of a canonical PLT (which changes STT_GNU_IFUNC to STT_FUNC and redirects all references): 1) GOT-generating (`needsGot`) 2) PLT-generating (`needsPlt`) 3) R_ABS with 0 addend in a writable location. This is used for for ifunc function pointers in writable sections such as .data and .toc. This patch deletes case 3) to simplify the R_*_IRELATIVE generating logic added in D57371. Other advantages: * It is guaranteed no more than 1 R_*_IRELATIVE is created for an ifunc. * PPC64: no need to special case ifunc in toc-indirect to toc-relative relaxation. See D65755 The deleted elf::addIRelativeRelocs demonstrates that one-pass scan through relocations makes several optimizations difficult. This is something we can think about in the future. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D65995 llvm-svn: 368661
* [ELF] Simplify handling of exportDynamic and isPreemptibleFangrui Song2019-08-134-23/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Writer::includeInDynSym(), exportDynamic is used by a Defined with protected or default visibility, to record whether it is required to be exported into .dynsym. It is set when any of the following conditions hold: 1) There is an interposable symbol from a DSO (Undefined or SharedSymbol with default visibility) 2) If -shared or --export-dynamic is specified, any symbol in an object file/bitcode sets this property, unless suppressed by canBeOmittedFromSymbolTable(). 3) --dynamic-list when producing an executable 4) protected symbol from a DSO preempted by copy relocation/canonical PLT when --ignore-{data,function}-address-equality is specified 5) ifunc is exported when -z ifunc-noplt is specified Bullet points 4) and 5) are irrelevant in this patch. Bullet 3) does not play well with 1) and 2). When -shared is specified, exportDynamic of most symbols is true. This makes it incapable to record --dynamic-list marked symbols. We thus have obscure: if (!config->shared) b->exportDynamic = true; else if (b->includeInDynsym()) b->isPreemptible = true; This patch adds another bit `Symbol::inDynamicList` to record 3). We can thus simplify handleDynamicList() by unifying the DSO and executable cases. It also allows us to simplify isPreemptible - now the field is only used in finalizeSections() and later stages. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D66091 llvm-svn: 368659
* [ELF] Rename odd variable names "New" after r365730. NFCFangrui Song2019-08-136-38/+35
| | | | | | | | | | New -> newSym or newFlags Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D66127 llvm-svn: 368651
* [ELF] Remove unnecessary assignment to `isPreemptible` in replaceWithDefined()Fangrui Song2019-08-121-1/+0
| | | | | | | After r368535, it is no longer used in the handling of VER_NDX_LOCAL. Drop it. llvm-svn: 368550
* [ELF] Remove redundant isDefined() in Symbol::computeBinding() and delete ↵Fangrui Song2019-08-112-5/+3
| | | | | | | | | | | | | | one redundant call site After r367869, VER_NDX_LOCAL can only be assigned to Defined and CommonSymbol. CommonSymbol becomes Defined after replaceCommonSymbols(), thus `versionId == VER_NDX_LOCAL` will imply `isDefined()`. In maybeReportUndefined(), computeBinding() is called when the symbol is unknown to be Undefined. computeBinding() != STB_LOCAL will always be true. llvm-svn: 368536
* [ELF] Remove redundant !isPreemptible in Symbol::computeBinding()Fangrui Song2019-08-111-1/+1
| | | | | | | | | | | | | | !isPreemptible was added in r343668 to fix PR39104: symbols redefined by replaceWithDefined() might be incorrectly considered STB_LOCAL if a version script specified `local: *;`. After r367869 (`config->defaultSymbolVersion` was removed), we will assign VER_NDX_LOCAL to only regular Defined and CommonSymbol, not Defined created by replaceWithDefined() (because scanVersionScript() is called before scanRelocations()). The !isPreemptible is thus redundant and can be deleted. llvm-svn: 368535
* [ELF] Remove unnecessary assignment to `used` in replaceWithDefinedFangrui Song2019-08-111-1/+0
| | | | | | | `Symbol::used` is used by Undefined and SharedSymbol to record if a .symtab entry is needed. It is of no use for Defined. llvm-svn: 368533
* [ELF] Expand regions for gaps due to explicit addressFangrui Song2019-08-091-0/+8
| | | | | | | | | | If the dot gets moved by an explicit section address, an empty gap between sections could be created. The encompassing region for the section being parsed needs to be expanded to include the gap. Differential Revision: https://reviews.llvm.org/D65722 Patch by Gabriel Smith! llvm-svn: 368379
* DebugInfo: Explicitly handle errors when parsing unit DIEsDavid Blaikie2019-08-091-0/+4
| | | | | | | | This ensures these errors produce a non-zero exit and improves the context (providing the name of the input object and section being parsed). llvm-svn: 368378
* ELF: Move sections referred to by __start_/__stop_ symbols into the main ↵Peter Collingbourne2019-08-091-0/+12
| | | | | | | | | | | | | | | | | | | | | partition. In the case where C identifier sections have SHF_LINK_ORDER they will most likely be placed in the same partition as the section that they are associated with. But unless this happens to be the main partition, this will cause them to be excluded from the range covered by the __start_ and __stop_ symbols, which may lead to incorrect program behaviour. So we need to move them all into the main partition so that they will be covered by the __start_ and __stop_ symbols. We may want to refine this approach later and allow different __start_/__stop_ symbol values for different partitions. This would only make sense for relocations from SHT_NOTE sections since they are duplicated into each partition. Differential Revision: https://reviews.llvm.org/D65909 llvm-svn: 368375
* [ELF][AArch64] Support for movz, movk tprel relocationsPeter Smith2019-08-081-0/+10
| | | | | | | | | | | | | | | | | This patch Implements the R_AARCH64_TLSLE_MOVW_TPREL_G*[_NC]. These are logically the same calculation as the existing TLSLE relocations with the result written back to mov[nz] and movk instructions. A typical code sequence is: movz x0, #:tprel_g2:foo // bits [47:32] of R_TLS with overflow check movk x0, #:tprel_g1_nc:foo // bits [31:16] of R_TLS with no overflow check movk x0, #:tprel_g0_nc:foo // bits [15:0] of R_TLS with no overflow check This type of code sequence is usually used with a large code model. Differential Revision: https://reviews.llvm.org/D65882 Fixes: PR42853 llvm-svn: 368293
* gdb-index: Wire up str_offsets section to avoid incorrect error message ↵David Blaikie2019-08-072-0/+6
| | | | | | | | | | about offsets_base There's still a need for a deeper fix to the way libDebugInfoDWARF error messages are propagated up to lld - if lld had exited non-zero on this error message we would've found the issue sooner. llvm-svn: 368229
* API update for change to LLVM's lib/DebugInfo/DWARFDavid Blaikie2019-08-073-21/+21
| | | | llvm-svn: 368190
* Re-submit r367649: Improve raw_ostream so that you can "write" colors using ↵Rui Ueyama2019-08-072-5/+5
| | | | | | | | | 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-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+13
| | | | | | | | | | | | | | | | | | 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-063-19/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Consistently prioritize non-* wildcards overs "*" in version scriptsFangrui Song2019-08-057-67/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud