llvm-project/lld/ELF/LinkerScript.h

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

359 lines
11 KiB
C
Raw Normal View History

//===- LinkerScript.h -------------------------------------------*- C++ -*-===//
//
// 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
//
//===----------------------------------------------------------------------===//
#ifndef LLD_ELF_LINKER_SCRIPT_H
#define LLD_ELF_LINKER_SCRIPT_H
#include "Config.h"
#include "Writer.h"
#include "lld/Common/LLVM.h"
#include "lld/Common/Strings.h"
#include "llvm/ADT/ArrayRef.h"
#include "llvm/ADT/DenseMap.h"
#include "llvm/ADT/DenseSet.h"
#include "llvm/ADT/MapVector.h"
#include "llvm/ADT/StringRef.h"
#include "llvm/Support/MemoryBuffer.h"
#include <cstddef>
#include <cstdint>
#include <functional>
#include <memory>
#include <vector>
namespace lld {
2016-02-28 08:25:54 +08:00
namespace elf {
class Defined;
class InputFile;
class InputSection;
class InputSectionBase;
class OutputSection;
class SectionBase;
class Symbol;
class ThunkSection;
2017-10-11 08:01:49 +08:00
// This represents an r-value in the linker script.
struct ExprValue {
ExprValue(SectionBase *sec, bool forceAbsolute, uint64_t val,
const Twine &loc)
2017-10-11 08:01:49 +08:00
: sec(sec), forceAbsolute(forceAbsolute), val(val), loc(loc.str()) {}
ExprValue(uint64_t val) : ExprValue(nullptr, false, val, "") {}
bool isAbsolute() const { return forceAbsolute || sec == nullptr; }
uint64_t getValue() const;
uint64_t getSecAddr() const;
uint64_t getSectionOffset() const;
2017-10-11 08:01:49 +08:00
// If a value is relative to a section, it has a non-null Sec.
SectionBase *sec;
// True if this expression is enclosed in ABSOLUTE().
// This flag affects the return value of getValue().
bool forceAbsolute;
uint64_t val;
uint64_t alignment = 1;
// The original st_type if the expression represents a symbol. Any operation
// resets type to STT_NOTYPE.
uint8_t type = llvm::ELF::STT_NOTYPE;
2017-10-11 08:01:49 +08:00
// Original source location. Used for error messages.
std::string loc;
};
2016-10-14 07:08:33 +08:00
// This represents an expression in the linker script.
// ScriptParser::readExpr reads an expression and returns an Expr.
// Later, we evaluate the expression by calling the function.
using Expr = std::function<ExprValue()>;
Make readExpr return an Expr object instead of a vector of tokens. Previously, we handled an expression as a vector of tokens. In other words, an expression was a vector of uncooked raw StringRefs. When we need a value of an expression, we used ExprParser to run the expression. The separation was needed essentially because parse time is too early to evaluate an expression. In order to evaluate an expression, we need to finalize section sizes. Because linker script parsing is done at very early stage of the linking process, we can't evaluate expressions while parsing. The above mechanism worked fairly well, but there were a few drawbacks. One thing is that we sometimes have to parse the same expression more than once in order to find the end of the expression. In some contexts, linker script expressions have no clear end marker. So, we needed to recognize balanced expressions and ternary operators. The other is poor error reporting. Since expressions are parsed basically twice, and some information that is available at the first stage is lost in the second stage, it was hard to print out apprpriate error messages. This patch fixes the issues with a new approach. Now the expression parsing is integrated into ScriptParser. ExprParser class is removed. Expressions are represented as lambdas instead of vectors of tokens. Lambdas captures information they need to run themselves when they are created. In this way, ends of expressions are naturally detected, and errors are handled in the usual way. This patch also reduces the amount of code. Differential Revision: https://reviews.llvm.org/D22728 llvm-svn: 276574
2016-07-25 02:19:40 +08:00
// This enum is used to implement linker script SECTIONS command.
// https://sourceware.org/binutils/docs/ld/SECTIONS.html#SECTIONS
enum SectionsCommandKind {
AssignmentKind, // . = expr or <sym> = expr
OutputSectionKind,
InputSectionKind,
ByteKind // BYTE(expr), SHORT(expr), LONG(expr) or QUAD(expr)
};
struct BaseCommand {
BaseCommand(int k) : kind(k) {}
int kind;
};
2016-10-14 07:08:33 +08:00
// This represents ". = <expr>" or "<symbol> = <expr>".
struct SymbolAssignment : BaseCommand {
SymbolAssignment(StringRef name, Expr e, std::string loc)
: BaseCommand(AssignmentKind), name(name), expression(e), location(loc) {}
static bool classof(const BaseCommand *c) {
return c->kind == AssignmentKind;
}
2016-07-29 13:52:33 +08:00
// The LHS of an expression. Name is either a symbol name or ".".
StringRef name;
Defined *sym = nullptr;
2016-07-29 13:52:33 +08:00
// The RHS of an expression.
Make readExpr return an Expr object instead of a vector of tokens. Previously, we handled an expression as a vector of tokens. In other words, an expression was a vector of uncooked raw StringRefs. When we need a value of an expression, we used ExprParser to run the expression. The separation was needed essentially because parse time is too early to evaluate an expression. In order to evaluate an expression, we need to finalize section sizes. Because linker script parsing is done at very early stage of the linking process, we can't evaluate expressions while parsing. The above mechanism worked fairly well, but there were a few drawbacks. One thing is that we sometimes have to parse the same expression more than once in order to find the end of the expression. In some contexts, linker script expressions have no clear end marker. So, we needed to recognize balanced expressions and ternary operators. The other is poor error reporting. Since expressions are parsed basically twice, and some information that is available at the first stage is lost in the second stage, it was hard to print out apprpriate error messages. This patch fixes the issues with a new approach. Now the expression parsing is integrated into ScriptParser. ExprParser class is removed. Expressions are represented as lambdas instead of vectors of tokens. Lambdas captures information they need to run themselves when they are created. In this way, ends of expressions are naturally detected, and errors are handled in the usual way. This patch also reduces the amount of code. Differential Revision: https://reviews.llvm.org/D22728 llvm-svn: 276574
2016-07-25 02:19:40 +08:00
Expr expression;
2016-07-29 13:52:33 +08:00
// Command attributes for PROVIDE, HIDDEN and PROVIDE_HIDDEN.
bool provide = false;
bool hidden = false;
// Holds file name and line number for error reporting.
std::string location;
// A string representation of this command. We use this for -Map.
std::string commandString;
// Address of this assignment command.
uint64_t addr;
// Size of this assignment command. This is usually 0, but if
// you move '.' this may be greater than 0.
uint64_t size;
};
// Linker scripts allow additional constraints to be put on output sections.
2016-10-14 07:08:33 +08:00
// If an output section is marked as ONLY_IF_RO, the section is created
// only if its input sections are read-only. Likewise, an output section
// with ONLY_IF_RW is created if all input sections are RW.
enum class ConstraintKind { NoConstraint, ReadOnly, ReadWrite };
// This struct is used to represent the location and size of regions of
// target memory. Instances of the struct are created by parsing the
// MEMORY command.
struct MemoryRegion {
MemoryRegion(StringRef name, Expr origin, Expr length, uint32_t flags,
uint32_t negFlags)
: name(std::string(name)), origin(origin), length(length), flags(flags),
negFlags(negFlags) {}
[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 name;
Expr origin;
Expr length;
uint32_t flags;
uint32_t negFlags;
uint64_t curPos = 0;
};
// This struct represents one section match pattern in SECTIONS() command.
// It can optionally have negative match pattern for EXCLUDED_FILE command.
// Also it may be surrounded with SORT() command, so contains sorting rules.
class SectionPattern {
StringMatcher excludedFilePat;
// Cache of the most recent input argument and result of excludesFile().
mutable llvm::Optional<std::pair<const InputFile *, bool>> excludesFileCache;
public:
SectionPattern(StringMatcher &&pat1, StringMatcher &&pat2)
: excludedFilePat(pat1), sectionPat(pat2),
sortOuter(SortSectionPolicy::Default),
sortInner(SortSectionPolicy::Default) {}
[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
bool excludesFile(const InputFile *file) const;
StringMatcher sectionPat;
SortSectionPolicy sortOuter;
SortSectionPolicy sortInner;
};
class InputSectionDescription : public BaseCommand {
SingleStringMatcher filePat;
// Cache of the most recent input argument and result of matchesFile().
mutable llvm::Optional<std::pair<const InputFile *, bool>> matchesFileCache;
public:
InputSectionDescription(StringRef filePattern, uint64_t withFlags = 0,
uint64_t withoutFlags = 0)
: BaseCommand(InputSectionKind), filePat(filePattern),
withFlags(withFlags), withoutFlags(withoutFlags) {}
static bool classof(const BaseCommand *c) {
return c->kind == InputSectionKind;
}
bool matchesFile(const InputFile *file) const;
// Input sections that matches at least one of SectionPatterns
// will be associated with this InputSectionDescription.
std::vector<SectionPattern> sectionPatterns;
// Includes InputSections and MergeInputSections. Used temporarily during
// assignment of input sections to output sections.
std::vector<InputSectionBase *> sectionBases;
// Used after the finalizeInputSections() pass. MergeInputSections have been
// merged into MergeSyntheticSections.
std::vector<InputSection *> sections;
// Temporary record of synthetic ThunkSection instances and the pass that
// they were created in. This is used to insert newly created ThunkSections
// into Sections at the end of a createThunks() pass.
std::vector<std::pair<ThunkSection *, uint32_t>> thunkSections;
// SectionPatterns can be filtered with the INPUT_SECTION_FLAGS command.
uint64_t withFlags;
uint64_t withoutFlags;
};
2016-10-14 07:08:33 +08:00
// Represents BYTE(), SHORT(), LONG(), or QUAD().
struct ByteCommand : BaseCommand {
ByteCommand(Expr e, unsigned size, std::string commandString)
: BaseCommand(ByteKind), commandString(commandString), expression(e),
size(size) {}
static bool classof(const BaseCommand *c) { return c->kind == ByteKind; }
// Keeps string representing the command. Used for -Map" is perhaps better.
std::string commandString;
Expr expression;
// This is just an offset of this assignment command in the output section.
unsigned offset;
// Size of this data command.
unsigned size;
};
struct InsertCommand {
[ELF] Add OVERWRITE_SECTIONS command This implements https://sourceware.org/bugzilla/show_bug.cgi?id=26404 An `OVERWRITE_SECTIONS` command is a `SECTIONS` variant which contains several output section descriptions. The output sections do not have specify an order. Similar to `INSERT [BEFORE|AFTER]`, `LinkerScript::hasSectionsCommand` is not set, so the built-in rules (see `docs/ELF/linker_script.rst`) still apply. `OVERWRITE_SECTIONS` can be more convenient than `INSERT` because it does not need an anchor section. The initial syntax is intentionally narrow to facilitate backward compatible extensions in the future. Symbol assignments cannot be used. This feature is versatile. To list a few usage: * Use `section : { KEEP(...) }` to retain input sections under GC * Define encapsulation symbols (start/end) for an output section * Use `section : ALIGN(...) : { ... }` to overalign an output section (similar to ld64 `-sectalign`) When an output section is specified by both `OVERWRITE_SECTIONS` and `INSERT`, `INSERT` is processed after overwrite sections. To make this work, this patch changes `InsertCommand` to use name based matching instead of pointer based matching. (This may cause a difference when `INSERT` moves one output section more than once. Such duplicate commands should not be used in practice (seems that in GNU ld the output sections may just disappear).) A linker script can be used without -T/--script. The traditional `SECTIONS` commands are concatenated, so a wrong rule can be more noticeable from the section order. This feature if misused can be less noticeable, just like `INSERT`. Differential Revision: https://reviews.llvm.org/D103303
2021-06-14 03:41:11 +08:00
StringRef name;
bool isAfter;
StringRef where;
};
struct PhdrsCommand {
StringRef name;
unsigned type = llvm::ELF::PT_NULL;
bool hasFilehdr = false;
bool hasPhdrs = false;
llvm::Optional<unsigned> flags;
Expr lmaExpr = nullptr;
};
class LinkerScript final {
// Temporary state used in processSectionCommands() and assignAddresses()
// that must be reinitialized for each call to the above functions, and must
// not be used outside of the scope of a call to the above functions.
struct AddressState {
AddressState();
uint64_t threadBssOffset = 0;
OutputSection *outSec = nullptr;
MemoryRegion *memRegion = nullptr;
MemoryRegion *lmaRegion = nullptr;
2018-01-26 00:43:49 +08:00
uint64_t lmaOffset = 0;
};
llvm::DenseMap<StringRef, OutputSection *> nameToOutputSection;
void addSymbol(SymbolAssignment *cmd);
void assignSymbol(SymbolAssignment *cmd, bool inSec);
void setDot(Expr e, const Twine &loc, bool inSec);
void expandOutputSection(uint64_t size);
void expandMemoryRegions(uint64_t size);
std::vector<InputSectionBase *>
computeInputSections(const InputSectionDescription *,
ArrayRef<InputSectionBase *>);
std::vector<InputSectionBase *> createInputSectionList(OutputSection &cmd);
void discardSynthetic(OutputSection &);
std::vector<size_t> getPhdrIndices(OutputSection *sec);
MemoryRegion *findMemoryRegion(OutputSection *sec);
void switchTo(OutputSection *sec);
uint64_t advance(uint64_t size, unsigned align);
void output(InputSection *sec);
void assignOffsets(OutputSection *sec);
// Ctx captures the local AddressState and makes it accessible
// deliberately. This is needed as there are some cases where we cannot just
// thread the current state through to a lambda function created by the
// script parser.
// This should remain a plain pointer as its lifetime is smaller than
// LinkerScript.
AddressState *ctx = nullptr;
OutputSection *aether;
uint64_t dot;
public:
OutputSection *createOutputSection(StringRef name, StringRef location);
OutputSection *getOrCreateOutputSection(StringRef name);
bool hasPhdrsCommands() { return !phdrsCommands.empty(); }
uint64_t getDot() { return dot; }
void discard(InputSectionBase *s);
ExprValue getSymbolValue(StringRef name, const Twine &loc);
void addOrphanSections();
void diagnoseOrphanHandling() const;
void adjustSectionsBeforeSorting();
void adjustSectionsAfterSorting();
std::vector<PhdrEntry *> createPhdrs();
bool needsInterpSection();
bool shouldKeep(InputSectionBase *s);
[ELF] Make LinkerScript::assignAddresses iterative PR42990. For `SECTIONS { b = a; . = 0xff00 + (a >> 8); a = .; }`, we currently set st_value(a)=0xff00 while st_value(b)=0xffff. The following call tree demonstrates the problem: ``` link<ELF64LE>(Args); Script->declareSymbols(); // insert a and b as absolute Defined Writer<ELFT>().run(); Script->processSectionCommands(); addSymbol(cmd); // a and b are re-inserted. LinkerScript::getSymbolValue // is lazily called by subsequent evaluation finalizeSections(); forEachRelSec(scanRelocations<ELFT>); processRelocAux // another problem PR42506, not affected by this patch finalizeAddressDependentContent(); // loop executed once script->assignAddresses(); // a = 0, b = 0xff00 script->assignAddresses(); // a = 0xff00, _end = 0xffff ``` We need another assignAddresses() to finalize the value of `a`. This patch 1) modifies assignAddress() to track the original section/value of each symbol and return a symbol whose section/value has changed. 2) moves the post-finalizeSections assignAddress() inside the loop of finalizeAddressDependentContent() and makes it iterative. Symbol assignment may not converge so we make a few attempts before bailing out. Note, assignAddresses() must be called at least twice. The penultimate call finalized section addresses while the last finalized symbol values. It is somewhat obscure and there was no comment. linkerscript/addr-zero.test tests this. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D66279 llvm-svn: 369889
2019-08-26 18:23:31 +08:00
const Defined *assignAddresses();
void allocateHeaders(std::vector<PhdrEntry *> &phdrs);
void processSectionCommands();
void processSymbolAssignments();
void declareSymbols();
// Used to handle INSERT AFTER statements.
void processInsertCommands();
// SECTIONS command list.
std::vector<BaseCommand *> sectionCommands;
// PHDRS command list.
std::vector<PhdrsCommand> phdrsCommands;
bool hasSectionsCommand = false;
bool errorOnMissingSection = false;
// List of section patterns specified with KEEP commands. They will
// be kept even if they are unused and --gc-sections is specified.
std::vector<InputSectionDescription *> keptSections;
// A map from memory region name to a memory region descriptor.
llvm::MapVector<llvm::StringRef, MemoryRegion *> memoryRegions;
// A list of symbols referenced by the script.
std::vector<llvm::StringRef> referencedSymbols;
// Used to implement INSERT [AFTER|BEFORE]. Contains output sections that need
// to be reordered.
std::vector<InsertCommand> insertCommands;
[ELF] Add OVERWRITE_SECTIONS command This implements https://sourceware.org/bugzilla/show_bug.cgi?id=26404 An `OVERWRITE_SECTIONS` command is a `SECTIONS` variant which contains several output section descriptions. The output sections do not have specify an order. Similar to `INSERT [BEFORE|AFTER]`, `LinkerScript::hasSectionsCommand` is not set, so the built-in rules (see `docs/ELF/linker_script.rst`) still apply. `OVERWRITE_SECTIONS` can be more convenient than `INSERT` because it does not need an anchor section. The initial syntax is intentionally narrow to facilitate backward compatible extensions in the future. Symbol assignments cannot be used. This feature is versatile. To list a few usage: * Use `section : { KEEP(...) }` to retain input sections under GC * Define encapsulation symbols (start/end) for an output section * Use `section : ALIGN(...) : { ... }` to overalign an output section (similar to ld64 `-sectalign`) When an output section is specified by both `OVERWRITE_SECTIONS` and `INSERT`, `INSERT` is processed after overwrite sections. To make this work, this patch changes `InsertCommand` to use name based matching instead of pointer based matching. (This may cause a difference when `INSERT` moves one output section more than once. Such duplicate commands should not be used in practice (seems that in GNU ld the output sections may just disappear).) A linker script can be used without -T/--script. The traditional `SECTIONS` commands are concatenated, so a wrong rule can be more noticeable from the section order. This feature if misused can be less noticeable, just like `INSERT`. Differential Revision: https://reviews.llvm.org/D103303
2021-06-14 03:41:11 +08:00
// OutputSections specified by OVERWRITE_SECTIONS.
std::vector<OutputSection *> overwriteSections;
// Sections that will be warned/errored by --orphan-handling.
std::vector<const InputSectionBase *> orphanSections;
};
extern LinkerScript *script;
} // end namespace elf
} // end namespace lld
#endif // LLD_ELF_LINKER_SCRIPT_H