llvm-project/lld/ELF/Symbols.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

706 lines
23 KiB
C++
Raw Normal View History

//===- Symbols.cpp --------------------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "Symbols.h"
#include "InputFiles.h"
#include "InputSection.h"
#include "OutputSections.h"
#include "SyntheticSections.h"
#include "Target.h"
#include "Writer.h"
#include "lld/Common/ErrorHandler.h"
#include "lld/Common/Strings.h"
#include <cstring>
using namespace llvm;
using namespace llvm::object;
using namespace llvm::ELF;
using namespace lld;
using namespace lld::elf;
std::string lld::toString(const elf::Symbol &sym) {
StringRef name = sym.getName();
std::string ret = demangle(name, config->demangle);
const char *suffix = sym.getVersionSuffix();
if (*suffix == '@')
ret += suffix;
return ret;
}
Defined *ElfSym::bss;
Defined *ElfSym::etext1;
Defined *ElfSym::etext2;
Defined *ElfSym::edata1;
Defined *ElfSym::edata2;
Defined *ElfSym::end1;
Defined *ElfSym::end2;
Defined *ElfSym::globalOffsetTable;
Defined *ElfSym::mipsGp;
Defined *ElfSym::mipsGpDisp;
Defined *ElfSym::mipsLocalGp;
Defined *ElfSym::relaIpltStart;
Defined *ElfSym::relaIpltEnd;
Defined *ElfSym::riscvGlobalPointer;
Defined *ElfSym::tlsModuleBase;
DenseMap<const Symbol *, std::pair<const InputFile *, const InputFile *>>
elf::backwardReferences;
[ELF] Add --why-extract= to query why archive members/lazy object files are extracted Similar to D69607 but for archive member extraction unrelated to GC. This patch adds --why-extract=. Prior art: GNU ld -M prints ``` Archive member included to satisfy reference by file (symbol) a.a(a.o) main.o (a) b.a(b.o) (b()) ``` -M is mainly for input section/symbol assignment <-> output section mapping (often huge output) and the information may appear ad-hoc. Apple ld64 ``` __Z1bv forced load of b.a(b.o) _a forced load of a.a(a.o) ``` It doesn't say the reference file. Arm's proprietary linker ``` Selecting member vsnprintf.o(c_wfu.l) to define vsnprintf. ... Loading member vsnprintf.o from c_wfu.l. definition: vsnprintf reference : _printf_a ``` --- --why-extract= gives the user the full data (which is much shorter than GNU ld -Map). It is easy to track a chain of references to one archive member with a one-liner, e.g. ``` % ld.lld main.o a_b.a b_c.a c.a -o /dev/null --why-extract=- | tee stdout reference extracted symbol main.o a_b.a(a_b.o) a a_b.a(a_b.o) b_c.a(b_c.o) b() b_c.a(b_c.o) c.a(c.o) c() % ruby -ane 'BEGIN{p={}}; p[$F[1]]=[$F[0],$F[2]] if $.>1; END{x="c.a(c.o)"; while y=p[x]; puts "#{y[0]} extracts #{x} to resolve #{y[1]}"; x=y[0] end}' stdout b_c.a(b_c.o) extracts c.a(c.o) to resolve c() a_b.a(a_b.o) extracts b_c.a(b_c.o) to resolve b() main.o extracts a_b.a(a_b.o) to resolve a ``` Archive member extraction happens before --gc-sections, so this may not be a live path under --gc-sections, but I think it is a good approximation in practice. * Specifying a file avoids output interleaving with --verbose. * Required `=` prevents accidental overwrite of an input if the user forgets `=`. (Most of compiler drivers' long options accept `=` but not ` `) Differential Revision: https://reviews.llvm.org/D109572
2021-09-21 00:52:30 +08:00
SmallVector<std::tuple<std::string, const InputFile *, const Symbol &>, 0>
elf::whyExtract;
SmallVector<SymbolAux, 0> elf::symAux;
[Coding style change] Rename variables so that they start with a lowercase 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
2019-07-10 13:00:37 +08:00
static uint64_t getSymVA(const Symbol &sym, int64_t addend) {
switch (sym.kind()) {
case Symbol::DefinedKind: {
auto &d = cast<Defined>(sym);
SectionBase *isec = d.section;
// This is an absolute symbol.
if (!isec)
return d.value;
Reland D61583 [ELF] Error on relocations to STT_SECTION symbols if the 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
2019-06-26 16:09:08 +08:00
assert(isec != &InputSection::discarded);
uint64_t offset = d.value;
// An object in an SHF_MERGE section might be referenced via a
// section symbol (as a hack for reducing the number of local
// symbols).
// Depending on the addend, the reference via a section symbol
// refers to a different object in the merge section.
// Since the objects in the merge section are not necessarily
// contiguous in the output, the addend can thus affect the final
// VA in a non-linear way.
// To make this work, we incorporate the addend into the section
// offset (and zero out the addend for later processing) so that
// we find the right object in the section.
if (d.isSection())
offset += addend;
// In the typical case, this is actually very simple and boils
// down to adding together 3 numbers:
// 1. The address of the output section.
// 2. The offset of the input section within the output section.
// 3. The offset within the input section (this addition happens
// inside InputSection::getOffset).
//
// If you understand the data structures involved with this next
// line (and how they get built), then you have a pretty good
// understanding of the linker.
uint64_t va = isec->getVA(offset);
if (d.isSection())
va -= addend;
[MIPS] Handle cross-mode (regular <-> microMIPS) jumps The patch solves two tasks: 1. MIPS ABI allows to mix regular and microMIPS code and perform cross-mode jumps. Linker needs to detect such cases and replace jump/branch instructions by their cross-mode equivalents. 2. Other tools like dunamic linkers need to recognize cases when dynamic table entries, e_entry field of an ELF header etc point to microMIPS symbol. Linker should provide such information. The first task is implemented in the `MIPS<ELFT>::relocateOne()` method. New routine `fixupCrossModeJump` detects ISA mode change, checks and replaces an instruction. The main problem is how to recognize that relocation target is microMIPS symbol. For absolute and section symbols compiler or assembler set the less-significant bit of the symbol's value or sum of the symbol's value and addend. And this bit signals to linker about microMIPS code. For global symbols compiler cannot do the same trick because other tools like, for example, disassembler wants to know an actual position of the symbol. So compiler sets STO_MIPS_MICROMIPS flag in the `st_other` field. In `MIPS<ELFT>::relocateOne()` method we have a symbol's value only and cannot access any symbol's attributes. To pass type of the symbol (regular/microMIPS) to that routine as well as other places where we write a symbol value as-is (.dynamic section, `Elf_Ehdr::e_entry` field etc) we set when necessary a less-significant bit in the `getSymVA` function. Differential revision: https://reviews.llvm.org/D40147 llvm-svn: 354311
2019-02-19 18:36:58 +08:00
// MIPS relocatable files can mix regular and microMIPS code.
// Linker needs to distinguish such code. To do so microMIPS
// symbols has the `STO_MIPS_MICROMIPS` flag in the `st_other`
// field. Unfortunately, the `MIPS::relocate()` method has
[MIPS] Handle cross-mode (regular <-> microMIPS) jumps The patch solves two tasks: 1. MIPS ABI allows to mix regular and microMIPS code and perform cross-mode jumps. Linker needs to detect such cases and replace jump/branch instructions by their cross-mode equivalents. 2. Other tools like dunamic linkers need to recognize cases when dynamic table entries, e_entry field of an ELF header etc point to microMIPS symbol. Linker should provide such information. The first task is implemented in the `MIPS<ELFT>::relocateOne()` method. New routine `fixupCrossModeJump` detects ISA mode change, checks and replaces an instruction. The main problem is how to recognize that relocation target is microMIPS symbol. For absolute and section symbols compiler or assembler set the less-significant bit of the symbol's value or sum of the symbol's value and addend. And this bit signals to linker about microMIPS code. For global symbols compiler cannot do the same trick because other tools like, for example, disassembler wants to know an actual position of the symbol. So compiler sets STO_MIPS_MICROMIPS flag in the `st_other` field. In `MIPS<ELFT>::relocateOne()` method we have a symbol's value only and cannot access any symbol's attributes. To pass type of the symbol (regular/microMIPS) to that routine as well as other places where we write a symbol value as-is (.dynamic section, `Elf_Ehdr::e_entry` field etc) we set when necessary a less-significant bit in the `getSymVA` function. Differential revision: https://reviews.llvm.org/D40147 llvm-svn: 354311
2019-02-19 18:36:58 +08:00
// a symbol value only. To pass type of the symbol (regular/microMIPS)
// to that routine as well as other places where we write
// a symbol value as-is (.dynamic section, `Elf_Ehdr::e_entry`
// field etc) do the same trick as compiler uses to mark microMIPS
// for CPU - set the less-significant bit.
if (config->emachine == EM_MIPS && isMicroMips() &&
((sym.stOther & STO_MIPS_MICROMIPS) || sym.needsCopy))
[MIPS] Handle cross-mode (regular <-> microMIPS) jumps The patch solves two tasks: 1. MIPS ABI allows to mix regular and microMIPS code and perform cross-mode jumps. Linker needs to detect such cases and replace jump/branch instructions by their cross-mode equivalents. 2. Other tools like dunamic linkers need to recognize cases when dynamic table entries, e_entry field of an ELF header etc point to microMIPS symbol. Linker should provide such information. The first task is implemented in the `MIPS<ELFT>::relocateOne()` method. New routine `fixupCrossModeJump` detects ISA mode change, checks and replaces an instruction. The main problem is how to recognize that relocation target is microMIPS symbol. For absolute and section symbols compiler or assembler set the less-significant bit of the symbol's value or sum of the symbol's value and addend. And this bit signals to linker about microMIPS code. For global symbols compiler cannot do the same trick because other tools like, for example, disassembler wants to know an actual position of the symbol. So compiler sets STO_MIPS_MICROMIPS flag in the `st_other` field. In `MIPS<ELFT>::relocateOne()` method we have a symbol's value only and cannot access any symbol's attributes. To pass type of the symbol (regular/microMIPS) to that routine as well as other places where we write a symbol value as-is (.dynamic section, `Elf_Ehdr::e_entry` field etc) we set when necessary a less-significant bit in the `getSymVA` function. Differential revision: https://reviews.llvm.org/D40147 llvm-svn: 354311
2019-02-19 18:36:58 +08:00
va |= 1;
if (d.isTls() && !config->relocatable) {
// Use the address of the TLS segment's first section rather than the
// segment's address, because segment addresses aren't initialized until
// after sections are finalized. (e.g. Measuring the size of .rela.dyn
// for Android relocation packing requires knowing TLS symbol addresses
// during section finalization.)
if (!Out::tlsPhdr || !Out::tlsPhdr->firstSec)
fatal(toString(d.file) +
" has an STT_TLS symbol but doesn't have an SHF_TLS section");
return va - Out::tlsPhdr->firstSec->addr;
}
return va;
}
case Symbol::SharedKind:
case Symbol::UndefinedKind:
return 0;
case Symbol::LazyObjectKind:
llvm_unreachable("lazy symbol reached writer");
case Symbol::CommonKind:
llvm_unreachable("common symbol reached writer");
case Symbol::PlaceholderKind:
llvm_unreachable("placeholder symbol reached writer");
}
llvm_unreachable("invalid symbol kind");
}
uint64_t Symbol::getVA(int64_t addend) const {
return getSymVA(*this, addend) + addend;
}
uint64_t Symbol::getGotVA() const {
if (gotInIgot)
return in.igotPlt->getVA() + getGotPltOffset();
return in.got->getVA() + getGotOffset();
}
uint64_t Symbol::getGotOffset() const {
return getGotIdx() * target->gotEntrySize;
}
uint64_t Symbol::getGotPltVA() const {
if (isInIplt)
return in.igotPlt->getVA() + getGotPltOffset();
return in.gotPlt->getVA() + getGotPltOffset();
}
uint64_t Symbol::getGotPltOffset() const {
if (isInIplt)
return getPltIdx() * target->gotEntrySize;
return (getPltIdx() + target->gotPltHeaderEntriesNum) * target->gotEntrySize;
}
uint64_t Symbol::getPltVA() const {
uint64_t outVA = isInIplt
? in.iplt->getVA() + getPltIdx() * target->ipltEntrySize
: in.plt->getVA() + in.plt->headerSize +
getPltIdx() * target->pltEntrySize;
[MIPS] Handle cross-mode (regular <-> microMIPS) jumps The patch solves two tasks: 1. MIPS ABI allows to mix regular and microMIPS code and perform cross-mode jumps. Linker needs to detect such cases and replace jump/branch instructions by their cross-mode equivalents. 2. Other tools like dunamic linkers need to recognize cases when dynamic table entries, e_entry field of an ELF header etc point to microMIPS symbol. Linker should provide such information. The first task is implemented in the `MIPS<ELFT>::relocateOne()` method. New routine `fixupCrossModeJump` detects ISA mode change, checks and replaces an instruction. The main problem is how to recognize that relocation target is microMIPS symbol. For absolute and section symbols compiler or assembler set the less-significant bit of the symbol's value or sum of the symbol's value and addend. And this bit signals to linker about microMIPS code. For global symbols compiler cannot do the same trick because other tools like, for example, disassembler wants to know an actual position of the symbol. So compiler sets STO_MIPS_MICROMIPS flag in the `st_other` field. In `MIPS<ELFT>::relocateOne()` method we have a symbol's value only and cannot access any symbol's attributes. To pass type of the symbol (regular/microMIPS) to that routine as well as other places where we write a symbol value as-is (.dynamic section, `Elf_Ehdr::e_entry` field etc) we set when necessary a less-significant bit in the `getSymVA` function. Differential revision: https://reviews.llvm.org/D40147 llvm-svn: 354311
2019-02-19 18:36:58 +08:00
// While linking microMIPS code PLT code are always microMIPS
// code. Set the less-significant bit to track that fact.
// See detailed comment in the `getSymVA` function.
if (config->emachine == EM_MIPS && isMicroMips())
outVA |= 1;
return outVA;
}
uint64_t Symbol::getSize() const {
if (const auto *dr = dyn_cast<Defined>(this))
return dr->size;
return cast<SharedSymbol>(this)->size;
}
OutputSection *Symbol::getOutputSection() const {
if (auto *s = dyn_cast<Defined>(this)) {
if (auto *sec = s->section)
return sec->getOutputSection();
return nullptr;
}
return nullptr;
}
// If a symbol name contains '@', the characters after that is
// a symbol version name. This function parses that.
void Symbol::parseSymbolVersion() {
// Return if localized by a local: pattern in a version script.
if (versionId == VER_NDX_LOCAL)
return;
StringRef s = getName();
size_t pos = s.find('@');
if (pos == StringRef::npos)
return;
StringRef verstr = s.substr(pos + 1);
// Truncate the symbol name so that it doesn't include the version string.
nameSize = pos;
if (verstr.empty())
return;
// If this is not in this DSO, it is not a definition.
if (!isDefined())
return;
// '@@' in a symbol name means the default version.
// It is usually the most recent one.
bool isDefault = (verstr[0] == '@');
if (isDefault)
verstr = verstr.substr(1);
for (const VersionDefinition &ver : namedVersionDefs()) {
if (ver.name != verstr)
continue;
if (isDefault)
versionId = ver.id;
else
versionId = ver.id | VERSYM_HIDDEN;
return;
}
// It is an error if the specified version is not defined.
// Usually version script is not provided when linking executable,
// but we may still want to override a versioned symbol from DSO,
// so we do not report error in this case. We also do not error
// if the symbol has a local version as it won't be in the dynamic
// symbol table.
if (config->shared && versionId != VER_NDX_LOCAL)
error(toString(file) + ": symbol " + s + " has undefined version " +
verstr);
}
void Symbol::extract() const {
[ELF] Parse archives as --start-lib object files https://maskray.me/blog/2022-01-16-archives-and-start-lib For every definition in an extracted archive member, we intern the symbol twice, once for the archive index entry, once for the .o symbol table after extraction. This is inefficient. Symbols in a --start-lib ObjFile/BitcodeFile are only interned once because the result is cached in symbols[i]. Just handle an archive using the --start-lib code path. We can therefore remove ArchiveFile and LazyArchive. For many projects, archive member extraction ratio is high and it is a net performance win. Linking a Release build of clang is 1.01x as fast. Note: --start-lib scans symbols in the same order that llvm-ar adds them to the index, so in the common case the semantics should be identical. If the archive symbol table was created in a different order, or is incomplete, this strategy may have different semantics. Such cases are considered user error. The `is neither ET_REL nor LLVM bitcode` error is changed to a warning. Previously an archive may have such members without a diagnostic. Using a warning prevents breakage. * For some tests, the diagnostics get improved where we did not consider the archive member name: `b.a:` => `b.a(b.o):`. * `no-obj.s`: the link is now allowed, matching GNU ld * `archive-no-index.s`: the `is neither ET_REL nor LLVM bitcode` diagnostic is demoted to a warning. * `incompatible.s`: even when an archive is unextracted, we may report an "incompatible with" error. --- I recently decreased sizeof(SymbolUnion) by 8 and decreased memory usage quite a bit, so retaining `symbols` for un-extracted archive members should not cause a memory usage problem. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D119074
2022-02-16 01:38:00 +08:00
if (file->lazy) {
file->lazy = false;
parseFile(file);
}
}
uint8_t Symbol::computeBinding() const {
if ((visibility != STV_DEFAULT && visibility != STV_PROTECTED) ||
versionId == VER_NDX_LOCAL)
return STB_LOCAL;
if (binding == STB_GNU_UNIQUE && !config->gnuUnique)
return STB_GLOBAL;
return binding;
}
bool Symbol::includeInDynsym() const {
if (computeBinding() == STB_LOCAL)
return false;
if (!isDefined() && !isCommon())
// This should unconditionally return true, unfortunately glibc -static-pie
// expects undefined weak symbols not to exist in .dynsym, e.g.
// __pthread_mutex_lock reference in _dl_add_to_namespace_list,
// __pthread_initialize_minimal reference in csu/libc-start.c.
return !(isUndefWeak() && config->noDynamicLinker);
return exportDynamic || inDynamicList;
}
// Print out a log message for --trace-symbol.
void elf::printTraceSymbol(const Symbol &sym, StringRef name) {
std::string s;
if (sym.isUndefined())
s = ": reference to ";
else if (sym.isLazy())
s = ": lazy definition of ";
else if (sym.isShared())
s = ": shared definition of ";
else if (sym.isCommon())
s = ": common definition of ";
else
s = ": definition of ";
message(toString(sym.file) + s + name);
}
[ELF] Add --why-extract= to query why archive members/lazy object files are extracted Similar to D69607 but for archive member extraction unrelated to GC. This patch adds --why-extract=. Prior art: GNU ld -M prints ``` Archive member included to satisfy reference by file (symbol) a.a(a.o) main.o (a) b.a(b.o) (b()) ``` -M is mainly for input section/symbol assignment <-> output section mapping (often huge output) and the information may appear ad-hoc. Apple ld64 ``` __Z1bv forced load of b.a(b.o) _a forced load of a.a(a.o) ``` It doesn't say the reference file. Arm's proprietary linker ``` Selecting member vsnprintf.o(c_wfu.l) to define vsnprintf. ... Loading member vsnprintf.o from c_wfu.l. definition: vsnprintf reference : _printf_a ``` --- --why-extract= gives the user the full data (which is much shorter than GNU ld -Map). It is easy to track a chain of references to one archive member with a one-liner, e.g. ``` % ld.lld main.o a_b.a b_c.a c.a -o /dev/null --why-extract=- | tee stdout reference extracted symbol main.o a_b.a(a_b.o) a a_b.a(a_b.o) b_c.a(b_c.o) b() b_c.a(b_c.o) c.a(c.o) c() % ruby -ane 'BEGIN{p={}}; p[$F[1]]=[$F[0],$F[2]] if $.>1; END{x="c.a(c.o)"; while y=p[x]; puts "#{y[0]} extracts #{x} to resolve #{y[1]}"; x=y[0] end}' stdout b_c.a(b_c.o) extracts c.a(c.o) to resolve c() a_b.a(a_b.o) extracts b_c.a(b_c.o) to resolve b() main.o extracts a_b.a(a_b.o) to resolve a ``` Archive member extraction happens before --gc-sections, so this may not be a live path under --gc-sections, but I think it is a good approximation in practice. * Specifying a file avoids output interleaving with --verbose. * Required `=` prevents accidental overwrite of an input if the user forgets `=`. (Most of compiler drivers' long options accept `=` but not ` `) Differential Revision: https://reviews.llvm.org/D109572
2021-09-21 00:52:30 +08:00
static void recordWhyExtract(const InputFile *reference,
const InputFile &extracted, const Symbol &sym) {
whyExtract.emplace_back(toString(reference), &extracted, sym);
}
void elf::maybeWarnUnorderableSymbol(const Symbol *sym) {
if (!config->warnSymbolOrdering)
return;
2018-04-26 09:38:29 +08:00
// If UnresolvedPolicy::Ignore is used, no "undefined symbol" error/warning
// is emitted. It makes sense to not warn on undefined symbols.
//
// Note, ld.bfd --symbol-ordering-file= does not warn on undefined symbols,
// but we don't have to be compatible here.
if (sym->isUndefined() &&
config->unresolvedSymbols == UnresolvedPolicy::Ignore)
return;
const InputFile *file = sym->file;
auto *d = dyn_cast<Defined>(sym);
[Coding style change] Rename variables so that they start with a lowercase 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
2019-07-10 13:00:37 +08:00
auto report = [&](StringRef s) { warn(toString(file) + s + sym->getName()); };
[Coding style change] Rename variables so that they start with a lowercase 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
2019-07-10 13:00:37 +08:00
if (sym->isUndefined())
report(": unable to order undefined symbol: ");
else if (sym->isShared())
report(": unable to order shared symbol: ");
else if (d && !d->section)
report(": unable to order absolute symbol: ");
else if (d && isa<OutputSection>(d->section))
report(": unable to order synthetic symbol: ");
else if (d && !d->section->isLive())
report(": unable to order discarded symbol: ");
}
// Returns true if a symbol can be replaced at load-time by a symbol
// with the same name defined in other ELF executable or DSO.
bool elf::computeIsPreemptible(const Symbol &sym) {
assert(!sym.isLocal() || sym.isPlaceholder());
// Only symbols with default visibility that appear in dynsym can be
// preempted. Symbols with protected visibility cannot be preempted.
if (!sym.includeInDynsym() || sym.visibility != STV_DEFAULT)
return false;
// At this point copy relocations have not been created yet, so any
// symbol that is not defined locally is preemptible.
if (!sym.isDefined())
return true;
if (!config->shared)
return false;
// If -Bsymbolic or --dynamic-list is specified, or -Bsymbolic-functions is
// specified and the symbol is STT_FUNC, the symbol is preemptible iff it is
[ELF] Add -Bsymbolic-non-weak-functions This option is a subset of -Bsymbolic-functions. It applies to STB_GLOBAL STT_FUNC definitions. The address of a vague linkage function (STB_WEAK STT_FUNC, e.g. an inline function, a template instantiation) seen by a -Bsymbolic-functions linked shared object may be different from the address seen from outside the shared object. Such cases are uncommon. (ELF/Mach-O programs may use `-fvisibility-inlines-hidden` to break such pointer equality. On Windows, correct dllexport and dllimport are needed to make pointer equality work. Windows link.exe enables /OPT:ICF by default so different inline functions may have the same address.) ``` // a.cc -> a.o -> a.so (-Bsymbolic-functions) inline void f() {} void *g() { return (void *)&f; } // b.cc -> b.o -> exe // The address is different! inline void f() {} ``` -Bsymbolic-non-weak-functions is a safer (C++ conforming) subset of -Bsymbolic-functions, which can make such programs work. Implementations usually emit a vague linkage definition in a COMDAT group. We could detect the group (with more code) but I feel that we should just check STB_WEAK for simplicity. A weak definition will thus serve as an escape hatch for rare cases when users want interposition on definitions. GNU ld feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=27871 Longer write-up: https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic If Linux distributions migrate to protected non-vague-linkage external linkage functions by default, the linker option can still be handy because it allows rapid experiment without recompilation. Protected function addresses currently have deep issues in GNU ld. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D102570
2021-07-30 05:46:53 +08:00
// in the dynamic list. -Bsymbolic-non-weak-functions is a non-weak subset of
// -Bsymbolic-functions.
if (config->symbolic ||
(config->bsymbolic == BsymbolicKind::Functions && sym.isFunc()) ||
(config->bsymbolic == BsymbolicKind::NonWeakFunctions && sym.isFunc() &&
sym.binding != STB_WEAK))
return sym.inDynamicList;
return true;
}
void elf::reportBackrefs() {
[ELF] --warn-backrefs: don't warn for linking sandwich problems This is an alternative design to D77512. D45195 added --warn-backrefs to detect * A. certain input orders which GNU ld either errors ("undefined reference") or has different resolution semantics * B. (byproduct) some latent multiple definition problems (-ldef1 -lref -ldef2) which I call "linking sandwich problems". def2 may or may not be the same as def1. When an archive appears more than once (-ldef -lref -ldef), lld and GNU ld may have the same resolution but --warn-backrefs may warn. This is not uncommon. For example, currently lld itself has such a problem: ``` liblldCommon.a liblldCOFF.a ... liblldCommon.a _ZN3lld10DWARFCache13getDILineInfoEmm in liblldCOFF.a refers to liblldCommon.a(DWARF.cpp.o) libLLVMSupport.a also appears twice and has a similar warning ``` glibc has such problems. It is somewhat destined because of its separate libc/libpthread/... and arbitrary grouping. The situation is getting improved over time but I have seen: ``` -lc __isnanl references -lm -lc _IO_funlockfile references -lpthread ``` There are also various issues in interaction with other runtime libraries such as libgcc_eh and libunwind: ``` -lc __gcc_personality_v0 references -lgcc_eh -lpthread __gcc_personality_v0 references -lgcc_eh -lpthread _Unwind_GetCFA references -lunwind ``` These problems are actually benign. We want --warn-backrefs to focus on its main task A and defer task B (which is also useful) to a more specific future feature (see gold --detect-odr-violations and https://bugs.llvm.org/show_bug.cgi?id=43110). Instead of warning immediately, we store the message and only report it if no subsequent lazy definition exists. The use of the static variable `backrefDiags` is similar to `undefs` in Relocations.cpp Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D77522
2020-04-06 13:27:46 +08:00
for (auto &it : backwardReferences) {
const Symbol &sym = *it.first;
std::string to = toString(it.second.second);
// Some libraries have known problems and can cause noise. Filter them out
// with --warn-backrefs-exclude=. to may look like *.o or *.a(*.o).
bool exclude = false;
for (const llvm::GlobPattern &pat : config->warnBackrefsExclude)
if (pat.match(to)) {
exclude = true;
break;
}
if (!exclude)
warn("backward reference detected: " + sym.getName() + " in " +
toString(it.second.first) + " refers to " + to);
[ELF] --warn-backrefs: don't warn for linking sandwich problems This is an alternative design to D77512. D45195 added --warn-backrefs to detect * A. certain input orders which GNU ld either errors ("undefined reference") or has different resolution semantics * B. (byproduct) some latent multiple definition problems (-ldef1 -lref -ldef2) which I call "linking sandwich problems". def2 may or may not be the same as def1. When an archive appears more than once (-ldef -lref -ldef), lld and GNU ld may have the same resolution but --warn-backrefs may warn. This is not uncommon. For example, currently lld itself has such a problem: ``` liblldCommon.a liblldCOFF.a ... liblldCommon.a _ZN3lld10DWARFCache13getDILineInfoEmm in liblldCOFF.a refers to liblldCommon.a(DWARF.cpp.o) libLLVMSupport.a also appears twice and has a similar warning ``` glibc has such problems. It is somewhat destined because of its separate libc/libpthread/... and arbitrary grouping. The situation is getting improved over time but I have seen: ``` -lc __isnanl references -lm -lc _IO_funlockfile references -lpthread ``` There are also various issues in interaction with other runtime libraries such as libgcc_eh and libunwind: ``` -lc __gcc_personality_v0 references -lgcc_eh -lpthread __gcc_personality_v0 references -lgcc_eh -lpthread _Unwind_GetCFA references -lunwind ``` These problems are actually benign. We want --warn-backrefs to focus on its main task A and defer task B (which is also useful) to a more specific future feature (see gold --detect-odr-violations and https://bugs.llvm.org/show_bug.cgi?id=43110). Instead of warning immediately, we store the message and only report it if no subsequent lazy definition exists. The use of the static variable `backrefDiags` is similar to `undefs` in Relocations.cpp Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D77522
2020-04-06 13:27:46 +08:00
}
}
static uint8_t getMinVisibility(uint8_t va, uint8_t vb) {
if (va == STV_DEFAULT)
return vb;
if (vb == STV_DEFAULT)
return va;
return std::min(va, vb);
}
// Merge symbol properties.
//
// When we have many symbols of the same name, we choose one of them,
// and that's the result of symbol resolution. However, symbols that
// were not chosen still affect some symbol properties.
void Symbol::mergeProperties(const Symbol &other) {
if (other.exportDynamic)
exportDynamic = true;
// DSO symbols do not affect visibility in the output.
if (!other.isShared())
visibility = getMinVisibility(visibility, other.visibility);
}
void Symbol::resolve(const Symbol &other) {
mergeProperties(other);
if (isPlaceholder()) {
replace(other);
return;
}
switch (other.kind()) {
case Symbol::UndefinedKind:
resolveUndefined(cast<Undefined>(other));
break;
case Symbol::CommonKind:
resolveCommon(cast<CommonSymbol>(other));
break;
case Symbol::DefinedKind:
resolveDefined(cast<Defined>(other));
break;
case Symbol::LazyObjectKind:
resolveLazy(cast<LazyObject>(other));
break;
case Symbol::SharedKind:
resolveShared(cast<SharedSymbol>(other));
break;
case Symbol::PlaceholderKind:
llvm_unreachable("bad symbol kind");
}
}
void Symbol::resolveUndefined(const Undefined &other) {
// An undefined symbol with non default visibility must be satisfied
// in the same DSO.
//
// If this is a non-weak defined symbol in a discarded section, override the
// existing undefined symbol for better error message later.
if ((isShared() && other.visibility != STV_DEFAULT) ||
(isUndefined() && other.binding != STB_WEAK && other.discardedSecIdx)) {
replace(other);
return;
}
if (traced)
printTraceSymbol(other, getName());
if (isLazy()) {
// An undefined weak will not extract archive members. See comment on Lazy
// in Symbols.h for the details.
if (other.binding == STB_WEAK) {
[ELF] Only allow the binding of SharedSymbol to change for the first undef ref 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
2019-07-02 19:37:21 +08:00
binding = STB_WEAK;
type = other.type;
return;
}
// Do extra check for --warn-backrefs.
//
// --warn-backrefs is an option to prevent an undefined reference from
// extracting an archive member written earlier in the command line. It can
// be used to keep compatibility with GNU linkers to some degree. I'll
// explain the feature and why you may find it useful in this comment.
//
// lld's symbol resolution semantics is more relaxed than traditional Unix
// linkers. For example,
//
// ld.lld foo.a bar.o
//
// succeeds even if bar.o contains an undefined symbol that has to be
// resolved by some object file in foo.a. Traditional Unix linkers don't
// allow this kind of backward reference, as they visit each file only once
// from left to right in the command line while resolving all undefined
// symbols at the moment of visiting.
//
// In the above case, since there's no undefined symbol when a linker visits
// foo.a, no files are pulled out from foo.a, and because the linker forgets
// about foo.a after visiting, it can't resolve undefined symbols in bar.o
// that could have been resolved otherwise.
//
// That lld accepts more relaxed form means that (besides it'd make more
// sense) you can accidentally write a command line or a build file that
// works only with lld, even if you have a plan to distribute it to wider
// users who may be using GNU linkers. With --warn-backrefs, you can detect
// a library order that doesn't work with other Unix linkers.
//
// The option is also useful to detect cyclic dependencies between static
// archives. Again, lld accepts
//
// ld.lld foo.a bar.a
//
// even if foo.a and bar.a depend on each other. With --warn-backrefs, it is
// handled as an error.
//
// Here is how the option works. We assign a group ID to each file. A file
// with a smaller group ID can pull out object files from an archive file
// with an equal or greater group ID. Otherwise, it is a reverse dependency
// and an error.
//
// A file outside --{start,end}-group gets a fresh ID when instantiated. All
// files within the same --{start,end}-group get the same group ID. E.g.
//
// ld.lld A B --start-group C D --end-group E
//
// A forms group 0. B form group 1. C and D (including their member object
// files) form group 2. E forms group 3. I think that you can see how this
// group assignment rule simulates the traditional linker's semantics.
bool backref = config->warnBackrefs && other.file &&
file->groupId < other.file->groupId;
extract();
[ELF] Add --why-extract= to query why archive members/lazy object files are extracted Similar to D69607 but for archive member extraction unrelated to GC. This patch adds --why-extract=. Prior art: GNU ld -M prints ``` Archive member included to satisfy reference by file (symbol) a.a(a.o) main.o (a) b.a(b.o) (b()) ``` -M is mainly for input section/symbol assignment <-> output section mapping (often huge output) and the information may appear ad-hoc. Apple ld64 ``` __Z1bv forced load of b.a(b.o) _a forced load of a.a(a.o) ``` It doesn't say the reference file. Arm's proprietary linker ``` Selecting member vsnprintf.o(c_wfu.l) to define vsnprintf. ... Loading member vsnprintf.o from c_wfu.l. definition: vsnprintf reference : _printf_a ``` --- --why-extract= gives the user the full data (which is much shorter than GNU ld -Map). It is easy to track a chain of references to one archive member with a one-liner, e.g. ``` % ld.lld main.o a_b.a b_c.a c.a -o /dev/null --why-extract=- | tee stdout reference extracted symbol main.o a_b.a(a_b.o) a a_b.a(a_b.o) b_c.a(b_c.o) b() b_c.a(b_c.o) c.a(c.o) c() % ruby -ane 'BEGIN{p={}}; p[$F[1]]=[$F[0],$F[2]] if $.>1; END{x="c.a(c.o)"; while y=p[x]; puts "#{y[0]} extracts #{x} to resolve #{y[1]}"; x=y[0] end}' stdout b_c.a(b_c.o) extracts c.a(c.o) to resolve c() a_b.a(a_b.o) extracts b_c.a(b_c.o) to resolve b() main.o extracts a_b.a(a_b.o) to resolve a ``` Archive member extraction happens before --gc-sections, so this may not be a live path under --gc-sections, but I think it is a good approximation in practice. * Specifying a file avoids output interleaving with --verbose. * Required `=` prevents accidental overwrite of an input if the user forgets `=`. (Most of compiler drivers' long options accept `=` but not ` `) Differential Revision: https://reviews.llvm.org/D109572
2021-09-21 00:52:30 +08:00
if (!config->whyExtract.empty())
recordWhyExtract(other.file, *file, *this);
// We don't report backward references to weak symbols as they can be
// overridden later.
[ELF] --warn-backrefs: don't warn for linking sandwich problems This is an alternative design to D77512. D45195 added --warn-backrefs to detect * A. certain input orders which GNU ld either errors ("undefined reference") or has different resolution semantics * B. (byproduct) some latent multiple definition problems (-ldef1 -lref -ldef2) which I call "linking sandwich problems". def2 may or may not be the same as def1. When an archive appears more than once (-ldef -lref -ldef), lld and GNU ld may have the same resolution but --warn-backrefs may warn. This is not uncommon. For example, currently lld itself has such a problem: ``` liblldCommon.a liblldCOFF.a ... liblldCommon.a _ZN3lld10DWARFCache13getDILineInfoEmm in liblldCOFF.a refers to liblldCommon.a(DWARF.cpp.o) libLLVMSupport.a also appears twice and has a similar warning ``` glibc has such problems. It is somewhat destined because of its separate libc/libpthread/... and arbitrary grouping. The situation is getting improved over time but I have seen: ``` -lc __isnanl references -lm -lc _IO_funlockfile references -lpthread ``` There are also various issues in interaction with other runtime libraries such as libgcc_eh and libunwind: ``` -lc __gcc_personality_v0 references -lgcc_eh -lpthread __gcc_personality_v0 references -lgcc_eh -lpthread _Unwind_GetCFA references -lunwind ``` These problems are actually benign. We want --warn-backrefs to focus on its main task A and defer task B (which is also useful) to a more specific future feature (see gold --detect-odr-violations and https://bugs.llvm.org/show_bug.cgi?id=43110). Instead of warning immediately, we store the message and only report it if no subsequent lazy definition exists. The use of the static variable `backrefDiags` is similar to `undefs` in Relocations.cpp Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D77522
2020-04-06 13:27:46 +08:00
//
// A traditional linker does not error for -ldef1 -lref -ldef2 (linking
// sandwich), where def2 may or may not be the same as def1. We don't want
// to warn for this case, so dismiss the warning if we see a subsequent lazy
// definition. this->file needs to be saved because in the case of LTO it
// may be reset to nullptr or be replaced with a file named lto.tmp.
if (backref && !isWeak())
backwardReferences.try_emplace(this, std::make_pair(other.file, file));
return;
}
// Undefined symbols in a SharedFile do not change the binding.
2021-12-25 13:22:27 +08:00
if (isa_and_nonnull<SharedFile>(other.file))
return;
[ELF] Make binding (weak or non-weak) logic consistent for Undefined and 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
2019-08-06 22:03:45 +08:00
if (isUndefined() || isShared()) {
// The binding will be weak if there is at least one reference and all are
// weak. The binding has one opportunity to change to weak: if the first
// reference is weak.
if (other.binding != STB_WEAK || !referenced)
binding = other.binding;
}
}
// Compare two symbols. Return 1 if the new symbol should win, -1 if
// the new symbol should lose, or 0 if there is a conflict.
int Symbol::compare(const Symbol *other) const {
assert(other->isDefined() || other->isCommon());
if (!isDefined() && !isCommon())
return 1;
// .symver foo,foo@@VER unfortunately creates two defined symbols: foo and
// foo@@VER. In GNU ld, if foo and foo@@VER are in the same file, foo is
// ignored. In our implementation, when this is foo, this->getName() may still
// contain @@, return 1 in this case as well.
if (file == other->file) {
if (other->getName().contains("@@"))
return 1;
if (getName().contains("@@"))
return -1;
}
if (other->isWeak())
return -1;
if (isWeak())
return 1;
if (isCommon() && other->isCommon()) {
if (config->warnCommon)
warn("multiple common of " + getName());
return 0;
}
if (isCommon()) {
if (config->warnCommon)
warn("common " + getName() + " is overridden");
return 1;
}
if (other->isCommon()) {
if (config->warnCommon)
warn("common " + getName() + " is overridden");
return -1;
}
return 0;
}
void elf::reportDuplicate(const Symbol &sym, InputFile *newFile,
InputSectionBase *errSec, uint64_t errOffset) {
if (config->allowMultipleDefinition)
return;
const Defined *d = cast<Defined>(&sym);
if (!d->section || !errSec) {
error("duplicate symbol: " + toString(sym) + "\n>>> defined in " +
toString(sym.file) + "\n>>> defined in " + toString(newFile));
return;
}
// Construct and print an error message in the form of:
//
// ld.lld: error: duplicate symbol: foo
// >>> defined at bar.c:30
// >>> bar.o (/home/alice/src/bar.o)
// >>> defined at baz.c:563
// >>> baz.o in archive libbaz.a
auto *sec1 = cast<InputSectionBase>(d->section);
std::string src1 = sec1->getSrcMsg(sym, d->value);
std::string obj1 = sec1->getObjMsg(d->value);
std::string src2 = errSec->getSrcMsg(sym, errOffset);
std::string obj2 = errSec->getObjMsg(errOffset);
[Coding style change] Rename variables so that they start with a lowercase 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
2019-07-10 13:00:37 +08:00
std::string msg = "duplicate symbol: " + toString(sym) + "\n>>> defined at ";
if (!src1.empty())
msg += src1 + "\n>>> ";
msg += obj1 + "\n>>> defined at ";
if (!src2.empty())
msg += src2 + "\n>>> ";
msg += obj2;
error(msg);
}
void Symbol::checkDuplicate(const Defined &other) const {
if (compare(&other) == 0)
reportDuplicate(*this, other.file,
dyn_cast_or_null<InputSectionBase>(other.section),
other.value);
}
void Symbol::resolveCommon(const CommonSymbol &other) {
int cmp = compare(&other);
if (cmp < 0)
return;
if (cmp > 0) {
if (auto *s = dyn_cast<SharedSymbol>(this)) {
// Increase st_size if the shared symbol has a larger st_size. The shared
// symbol may be created from common symbols. The fact that some object
// files were linked into a shared object first should not change the
// regular rule that picks the largest st_size.
uint64_t size = s->size;
replace(other);
if (size > cast<CommonSymbol>(this)->size)
cast<CommonSymbol>(this)->size = size;
} else {
replace(other);
}
return;
}
CommonSymbol *oldSym = cast<CommonSymbol>(this);
oldSym->alignment = std::max(oldSym->alignment, other.alignment);
if (oldSym->size < other.size) {
oldSym->file = other.file;
oldSym->size = other.size;
}
}
void Symbol::resolveDefined(const Defined &other) {
int cmp = compare(&other);
if (cmp > 0)
replace(other);
}
void Symbol::resolveLazy(const LazyObject &other) {
// For common objects, we want to look for global or weak definitions that
// should be extracted as the canonical definition instead.
if (isCommon() && elf::config->fortranCommon) {
[ELF] Parse archives as --start-lib object files https://maskray.me/blog/2022-01-16-archives-and-start-lib For every definition in an extracted archive member, we intern the symbol twice, once for the archive index entry, once for the .o symbol table after extraction. This is inefficient. Symbols in a --start-lib ObjFile/BitcodeFile are only interned once because the result is cached in symbols[i]. Just handle an archive using the --start-lib code path. We can therefore remove ArchiveFile and LazyArchive. For many projects, archive member extraction ratio is high and it is a net performance win. Linking a Release build of clang is 1.01x as fast. Note: --start-lib scans symbols in the same order that llvm-ar adds them to the index, so in the common case the semantics should be identical. If the archive symbol table was created in a different order, or is incomplete, this strategy may have different semantics. Such cases are considered user error. The `is neither ET_REL nor LLVM bitcode` error is changed to a warning. Previously an archive may have such members without a diagnostic. Using a warning prevents breakage. * For some tests, the diagnostics get improved where we did not consider the archive member name: `b.a:` => `b.a(b.o):`. * `no-obj.s`: the link is now allowed, matching GNU ld * `archive-no-index.s`: the `is neither ET_REL nor LLVM bitcode` diagnostic is demoted to a warning. * `incompatible.s`: even when an archive is unextracted, we may report an "incompatible with" error. --- I recently decreased sizeof(SymbolUnion) by 8 and decreased memory usage quite a bit, so retaining `symbols` for un-extracted archive members should not cause a memory usage problem. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D119074
2022-02-16 01:38:00 +08:00
if (auto *loSym = dyn_cast<LazyObject>(&other)) {
if (loSym->file->shouldExtractForCommon(getName())) {
backwardReferences.erase(this);
replace(other);
other.extract();
return;
}
}
}
[ELF] --warn-backrefs: don't warn for linking sandwich problems This is an alternative design to D77512. D45195 added --warn-backrefs to detect * A. certain input orders which GNU ld either errors ("undefined reference") or has different resolution semantics * B. (byproduct) some latent multiple definition problems (-ldef1 -lref -ldef2) which I call "linking sandwich problems". def2 may or may not be the same as def1. When an archive appears more than once (-ldef -lref -ldef), lld and GNU ld may have the same resolution but --warn-backrefs may warn. This is not uncommon. For example, currently lld itself has such a problem: ``` liblldCommon.a liblldCOFF.a ... liblldCommon.a _ZN3lld10DWARFCache13getDILineInfoEmm in liblldCOFF.a refers to liblldCommon.a(DWARF.cpp.o) libLLVMSupport.a also appears twice and has a similar warning ``` glibc has such problems. It is somewhat destined because of its separate libc/libpthread/... and arbitrary grouping. The situation is getting improved over time but I have seen: ``` -lc __isnanl references -lm -lc _IO_funlockfile references -lpthread ``` There are also various issues in interaction with other runtime libraries such as libgcc_eh and libunwind: ``` -lc __gcc_personality_v0 references -lgcc_eh -lpthread __gcc_personality_v0 references -lgcc_eh -lpthread _Unwind_GetCFA references -lunwind ``` These problems are actually benign. We want --warn-backrefs to focus on its main task A and defer task B (which is also useful) to a more specific future feature (see gold --detect-odr-violations and https://bugs.llvm.org/show_bug.cgi?id=43110). Instead of warning immediately, we store the message and only report it if no subsequent lazy definition exists. The use of the static variable `backrefDiags` is similar to `undefs` in Relocations.cpp Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D77522
2020-04-06 13:27:46 +08:00
if (!isUndefined()) {
// See the comment in resolveUndefined().
if (isDefined())
backwardReferences.erase(this);
return;
[ELF] --warn-backrefs: don't warn for linking sandwich problems This is an alternative design to D77512. D45195 added --warn-backrefs to detect * A. certain input orders which GNU ld either errors ("undefined reference") or has different resolution semantics * B. (byproduct) some latent multiple definition problems (-ldef1 -lref -ldef2) which I call "linking sandwich problems". def2 may or may not be the same as def1. When an archive appears more than once (-ldef -lref -ldef), lld and GNU ld may have the same resolution but --warn-backrefs may warn. This is not uncommon. For example, currently lld itself has such a problem: ``` liblldCommon.a liblldCOFF.a ... liblldCommon.a _ZN3lld10DWARFCache13getDILineInfoEmm in liblldCOFF.a refers to liblldCommon.a(DWARF.cpp.o) libLLVMSupport.a also appears twice and has a similar warning ``` glibc has such problems. It is somewhat destined because of its separate libc/libpthread/... and arbitrary grouping. The situation is getting improved over time but I have seen: ``` -lc __isnanl references -lm -lc _IO_funlockfile references -lpthread ``` There are also various issues in interaction with other runtime libraries such as libgcc_eh and libunwind: ``` -lc __gcc_personality_v0 references -lgcc_eh -lpthread __gcc_personality_v0 references -lgcc_eh -lpthread _Unwind_GetCFA references -lunwind ``` These problems are actually benign. We want --warn-backrefs to focus on its main task A and defer task B (which is also useful) to a more specific future feature (see gold --detect-odr-violations and https://bugs.llvm.org/show_bug.cgi?id=43110). Instead of warning immediately, we store the message and only report it if no subsequent lazy definition exists. The use of the static variable `backrefDiags` is similar to `undefs` in Relocations.cpp Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D77522
2020-04-06 13:27:46 +08:00
}
// An undefined weak will not extract archive members. See comment on Lazy in
// Symbols.h for the details.
if (isWeak()) {
uint8_t ty = type;
replace(other);
type = ty;
binding = STB_WEAK;
return;
}
[ELF] Add --why-extract= to query why archive members/lazy object files are extracted Similar to D69607 but for archive member extraction unrelated to GC. This patch adds --why-extract=. Prior art: GNU ld -M prints ``` Archive member included to satisfy reference by file (symbol) a.a(a.o) main.o (a) b.a(b.o) (b()) ``` -M is mainly for input section/symbol assignment <-> output section mapping (often huge output) and the information may appear ad-hoc. Apple ld64 ``` __Z1bv forced load of b.a(b.o) _a forced load of a.a(a.o) ``` It doesn't say the reference file. Arm's proprietary linker ``` Selecting member vsnprintf.o(c_wfu.l) to define vsnprintf. ... Loading member vsnprintf.o from c_wfu.l. definition: vsnprintf reference : _printf_a ``` --- --why-extract= gives the user the full data (which is much shorter than GNU ld -Map). It is easy to track a chain of references to one archive member with a one-liner, e.g. ``` % ld.lld main.o a_b.a b_c.a c.a -o /dev/null --why-extract=- | tee stdout reference extracted symbol main.o a_b.a(a_b.o) a a_b.a(a_b.o) b_c.a(b_c.o) b() b_c.a(b_c.o) c.a(c.o) c() % ruby -ane 'BEGIN{p={}}; p[$F[1]]=[$F[0],$F[2]] if $.>1; END{x="c.a(c.o)"; while y=p[x]; puts "#{y[0]} extracts #{x} to resolve #{y[1]}"; x=y[0] end}' stdout b_c.a(b_c.o) extracts c.a(c.o) to resolve c() a_b.a(a_b.o) extracts b_c.a(b_c.o) to resolve b() main.o extracts a_b.a(a_b.o) to resolve a ``` Archive member extraction happens before --gc-sections, so this may not be a live path under --gc-sections, but I think it is a good approximation in practice. * Specifying a file avoids output interleaving with --verbose. * Required `=` prevents accidental overwrite of an input if the user forgets `=`. (Most of compiler drivers' long options accept `=` but not ` `) Differential Revision: https://reviews.llvm.org/D109572
2021-09-21 00:52:30 +08:00
const InputFile *oldFile = file;
other.extract();
[ELF] Add --why-extract= to query why archive members/lazy object files are extracted Similar to D69607 but for archive member extraction unrelated to GC. This patch adds --why-extract=. Prior art: GNU ld -M prints ``` Archive member included to satisfy reference by file (symbol) a.a(a.o) main.o (a) b.a(b.o) (b()) ``` -M is mainly for input section/symbol assignment <-> output section mapping (often huge output) and the information may appear ad-hoc. Apple ld64 ``` __Z1bv forced load of b.a(b.o) _a forced load of a.a(a.o) ``` It doesn't say the reference file. Arm's proprietary linker ``` Selecting member vsnprintf.o(c_wfu.l) to define vsnprintf. ... Loading member vsnprintf.o from c_wfu.l. definition: vsnprintf reference : _printf_a ``` --- --why-extract= gives the user the full data (which is much shorter than GNU ld -Map). It is easy to track a chain of references to one archive member with a one-liner, e.g. ``` % ld.lld main.o a_b.a b_c.a c.a -o /dev/null --why-extract=- | tee stdout reference extracted symbol main.o a_b.a(a_b.o) a a_b.a(a_b.o) b_c.a(b_c.o) b() b_c.a(b_c.o) c.a(c.o) c() % ruby -ane 'BEGIN{p={}}; p[$F[1]]=[$F[0],$F[2]] if $.>1; END{x="c.a(c.o)"; while y=p[x]; puts "#{y[0]} extracts #{x} to resolve #{y[1]}"; x=y[0] end}' stdout b_c.a(b_c.o) extracts c.a(c.o) to resolve c() a_b.a(a_b.o) extracts b_c.a(b_c.o) to resolve b() main.o extracts a_b.a(a_b.o) to resolve a ``` Archive member extraction happens before --gc-sections, so this may not be a live path under --gc-sections, but I think it is a good approximation in practice. * Specifying a file avoids output interleaving with --verbose. * Required `=` prevents accidental overwrite of an input if the user forgets `=`. (Most of compiler drivers' long options accept `=` but not ` `) Differential Revision: https://reviews.llvm.org/D109572
2021-09-21 00:52:30 +08:00
if (!config->whyExtract.empty())
recordWhyExtract(oldFile, *file, *this);
}
void Symbol::resolveShared(const SharedSymbol &other) {
if (isCommon()) {
// See the comment in resolveCommon() above.
if (other.size > cast<CommonSymbol>(this)->size)
cast<CommonSymbol>(this)->size = other.size;
return;
}
if (visibility == STV_DEFAULT && (isUndefined() || isLazy())) {
// An undefined symbol with non default visibility must be satisfied
// in the same DSO.
uint8_t bind = binding;
replace(other);
binding = bind;
} else if (traced)
printTraceSymbol(other, getName());
}