summaryrefslogtreecommitdiffstats
path: root/lld/ELF
Commit message (Collapse)AuthorAgeFilesLines
...
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-053-3/+3
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* [ELF] Move R_*_IRELATIVE from .rel[a].plt to .rel[a].dyn unless ↵Fangrui Song2019-08-032-19/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --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 ℜ } 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-022-5/+5
| | | | | | | | 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-022-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-013-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Return early. NFC.Rui Ueyama2019-07-291-10/+10
| | | | llvm-svn: 367200
* [ELF] Simplify with dyn_cast_or_null. NFCFangrui Song2019-07-261-1/+1
| | | | llvm-svn: 367126
* [ELF] Detemplate maybeReportUndefined and copySectionsIntoPartitionsFangrui Song2019-07-262-4/+3
| | | | llvm-svn: 367117
* [mips] Assign R_TLS type to the R_MIPS_TLS_TPREL_XXX relocations. NFCSimon Atanasyan2019-07-242-8/+5
| | | | | | | | That allows to remove duplicated code which subtracts 0x7000 from the R_MIPS_TLS_TPREL_XXX relocations values in the `MIPS::relocateOne` function. llvm-svn: 366888
* ld.lld: Demangle symbols from archives in diagnosticsNico Weber2019-07-233-14/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ELF] Support explicitly overriding relocation model in LTOPetr Hosek2019-07-201-1/+3
| | | | | | | | 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: Add support for remaining R_AARCH64_MOVW* relocations.Peter Collingbourne2019-07-181-0/+60
| | | | | | Differential Revision: https://reviews.llvm.org/D64685 llvm-svn: 366466
* ELF: Allow forward references to linked sections.Peter Collingbourne2019-07-181-17/+21
| | | | | | | | | | | 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] Refactor some ppc64 testsFangrui Song2019-07-181-0/+1
| | | | | | | | 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
* [DWARF][RISCV] Add support for RISC-V relocations needed for debug infoAlex Bradbury2019-07-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When code relaxation is enabled many RISC-V fixups are not resolved but instead relocations are emitted. This happens even for DWARF debug sections. Therefore, to properly support the parsing of DWARF debug info we need to be able to resolve RISC-V relocations. This patch adds: * Support for RISC-V relocations in RelocationResolver * DWARF support for two relocations per object file offset * DWARF changes to support relocations in more DIE fields The two relocations per offset change is needed because some RISC-V relocations (used for label differences) come in pairs. Relocations can also be emitted for DWARF fields where relocations were not yet evaluated. Adding relocation support for some of these fields is essencial. On the other hand, LLVM currently emits RISC-V relocations for fixups that could be safely evaluated, since they can never be affected by code relaxations. This patch also adds relocation support for the fields affected by those extraneous relocations (the DWARF unit entry Length, and the DWARF debug line entry TotalLength and PrologueLength), for testing purposes. Differential Revision: https://reviews.llvm.org/D62062 Patch by Luís Marques. llvm-svn: 366402
* [lld] Add Visual Studio compatible diagnosticsChris Jackson2019-07-172-0/+5
| | | | | | | | | | | | 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
* [ELF] Delete redundant pageAlign at PT_GNU_RELRO boundaries after D58892Fangrui Song2019-07-171-19/+0
| | | | | | | | | | | | | | | | | | | | | | | Summary: After D58892 split the RW PT_LOAD on the PT_GNU_RELRO boundary, the new layout is: PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro)) PT_LOAD(.data. .bss) The two pageAlign() calls at PT_GNU_RELRO boundaries are redundant due to the existence of PT_LOAD. Reviewers: grimar, peter.smith, ruiu, espindola Reviewed By: ruiu Subscribers: sfertile, atanasyan, emaste, arichardson, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64854 llvm-svn: 366307
* [ELF] Fix variable names in comments after VariableName -> variableName changeFangrui Song2019-07-1622-97/+95
| | | | | | Also fix some typos. llvm-svn: 366181
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-164-14/+14
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* Re-land "[DebugInfo] Move function from line table to the prologue (NFC)"Jonas Devlieghere2019-07-161-1/+1
| | | | | | | | | | | | | | | | | In LLDB, when parsing type units, we don't need to parse the whole line table. Instead, we only need to parse the "support files" from the line table prologue. To make that possible, this patch moves the respective functions from the LineTable into the Prologue. Because I don't think users of the LineTable should have to know that these files come from the Prologue, I've left the original methods in place, and made them redirect to the LineTable. Differential revision: https://reviews.llvm.org/D64774 llvm-svn: 366164
* [LLD][ELF] - Minor simplification. NFC.George Rimar2019-07-151-4/+6
| | | | | | | | | | | | | | | | | This removes a call to `object::getSymbol<ELFT>`. We used this function in a next way: it was given an array of symbols and index and returned either a symbol at the index given or a error. This function was removed in D64631. (rL366052, but was reverted because of LLD compilation error that I didn't know about). It does not make much sense to keep this function on LLVM side only for LLD, because having only a list of symbols and the index it is not able to produce a valueable error message about context anyways. llvm-svn: 366057
* [ELF] Handle non-glob patterns before glob patterns in version scripts & fix ↵Fangrui Song2019-07-112-23/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-111-4/+15
| | | | | | | | | | | | | | | | | | | | | | 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
* Update comments for r365730. NFC.Rui Ueyama2019-07-111-13/+13
| | | | llvm-svn: 365733
* [Coding style change][lld] Rename variables for non-ELF portsRui Ueyama2019-07-1112-72/+72
| | | | | | | | | | | This patch does the same thing as r365595 to other subdirectories, which completes the naming style change for the entire lld directory. With this, the naming style conversion is complete for lld. Differential Revision: https://reviews.llvm.org/D64473 llvm-svn: 365730
* ELF: Add support for R_AARCH64_ADR_PREL_PG_HI21_NC relocation.Peter Collingbourne2019-07-101-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D64456 llvm-svn: 365662
* [LLD][ELF] - Linkerscript: fix FILL() expressions handling.George Rimar2019-07-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Coding style change] Rename variables so that they start with a lowercase ↵Rui Ueyama2019-07-1056-12292/+12292
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | letter This patch is mechanically generated by clang-llvm-rename tool that I wrote using Clang Refactoring Engine just for creating this patch. You can see the source code of the tool at https://reviews.llvm.org/D64123. There's no manual post-processing; you can generate the same patch by re-running the tool against lld's code base. Here is the main discussion thread to change the LLVM coding style: https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html In the discussion thread, I proposed we use lld as a testbed for variable naming scheme change, and this patch does that. I chose to rename variables so that they are in camelCase, just because that is a minimal change to make variables to start with a lowercase letter. Note to downstream patch maintainers: if you are maintaining a downstream lld repo, just rebasing ahead of this commit would cause massive merge conflicts because this patch essentially changes every line in the lld subdirectory. But there's a remedy. clang-llvm-rename tool is a batch tool, so you can rename variables in your downstream repo with the tool. Given that, here is how to rebase your repo to a commit after the mass renaming: 1. rebase to the commit just before the mass variable renaming, 2. apply the tool to your downstream repo to mass-rename variables locally, and 3. rebase again to the head. Most changes made by the tool should be identical for a downstream repo and for the head, so at the step 3, almost all changes should be merged and disappear. I'd expect that there would be some lines that you need to merge by hand, but that shouldn't be too many. Differential Revision: https://reviews.llvm.org/D64121 llvm-svn: 365595
* [ELF] Assert sizeof(SymbolUnion) <= 80Fangrui Song2019-07-091-0/+5
| | | | | | | | Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D64077 llvm-svn: 365443
* [LLD] NFC: Fixed GCC warning in ELF/Arch/RISCV.cppDenis Bakhvalov2019-07-091-1/+2
| | | | | | | | | GCC emits warning on this line: error: enumeral and non-enumeral type in conditional expression [-Werror=extra] Change-Id: I04969cc32e27e310968b88ebaa4e1c4894528d74 llvm-svn: 365434
* Let unaliased Args track which Alias they were created from, and use that in ↵Nico Weber2019-07-091-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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, llvm-dlltool, llvm-lib: Use getAsString() instead of getSpelling() for ↵Nico Weber2019-07-051-3/+3
| | | | | | | | | | | | | | | 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
* Make joined instances of JoinedOrSeparate flags point to the unaliased args, ↵Nico Weber2019-07-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | like all other arg types do This fixes an 8-year-old regression. r105763 made it so that aliases always refer to the unaliased option – but it missed the "joined" branch of JoinedOrSeparate flags. (r162231 then made the Args classes non-virtual, and r169344 moved them from clang to llvm.) Back then, there was no JoinedOrSeparate flag that was an alias, so it wasn't observable. Now /U in CLCompatOptions is a JoinedOrSeparate alias in clang, and warn_slash_u_filename incorrectly used the aliased arg id (using the unaliased one isn't really a regression since that warning checks if the undefined macro contains slash or backslash and only then emits the warning – and no valid use will pass "-Ufoo/bar" or similar). Also, lld has many JoinedOrSeparate aliases, and due to this bug it had to explicitly call `getUnaliasedOption()` in a bunch of places, even though that shouldn't be necessary by design. After this fix in Option, these calls really don't have an effect any more, so remove them. No intended behavior change. (I accidentally fixed this bug while working on PR29106 but then wondered why the warn_slash_u_filename broke. When I figured it out, I thought it would make sense to land this in a separate commit.) Differential Revision: https://reviews.llvm.org/D64156 llvm-svn: 365186
* [LLD][ELF] - Linkerscript: add a support for expressions for section's fillingGeorge Rimar2019-07-042-26/+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-041-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] resolveUndefined: ignore undefined symbols in SharedFile for Undefined ↵Fangrui Song2019-07-041-12/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+5
| | | | | | | | | | | | | | 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-031-2/+1
| | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | 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-031-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Avoid identifiers that are different only in case. NFC.Rui Ueyama2019-07-031-8/+8
| | | | llvm-svn: 365004
* Avoid identifiers that are different only in case. NFC.Rui Ueyama2019-07-035-35/+33
| | | | | | | | Some variables in lld have the same name as functions ignoring case. This patch gives them different names, so that my next patch is easier to read. llvm-svn: 365003
* [ELF] Error on archive with missing indexSam Clegg2019-07-031-1/+3
| | | | | | | | | | | | 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-031-0/+3
| | | | | | | | | | | 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-8/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-013-3/+40
| | | | | | | | | | | | 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-012-4/+118
| | | | | | | | | | | | | | | | | | | | * 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
* Cleanup: llvm::bsearch -> llvm::partition_point after r364719Fangrui Song2019-06-302-3/+3
| | | | llvm-svn: 364720
* [ELF] Do not produce DT_JMPREL and DT_PLTGOT if .rela.plt is empty.Igor Kudrin2019-06-281-1/+1
| | | | | | | | | | | | | 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
* Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the ↵Fangrui Song2019-06-265-27/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud