diff --git a/README.md b/README.md
index ef5c742b33..922a17db4e 100644
--- a/README.md
+++ b/README.md
@@ -8,9 +8,9 @@ end with a fully operational Zig compiler for any target.
This repository copies sources from upstream. Patches listed below. Use git
to find and inspect the patch diffs.
- * LLVM, LLD, Clang release/13.x (13.0.1-rc1+d4a57c84)
+ * LLVM, LLD, Clang 13.0.1
* zlib 1.2.11
- * Zig 0.9.0
+ * Zig 0.9.1
For other versions, check the git tags of this repository.
diff --git a/build b/build
index 9eb463fe7e..08805981d7 100755
--- a/build
+++ b/build
@@ -7,7 +7,7 @@ TARGET="$2" # Example: riscv64-linux-gnu
MCPU="$3" # Examples: `baseline`, `native`, `generic+v7a`, or `arm1176jzf_s`
ROOTDIR="$(pwd)"
-ZIG_VERSION="0.9.0"
+ZIG_VERSION="0.9.1"
TARGET_OS_AND_ABI=${TARGET#*-} # Example: linux-gnu
diff --git a/clang/lib/Analysis/CFG.cpp b/clang/lib/Analysis/CFG.cpp
index 0805642824..87c2f6f9f0 100644
--- a/clang/lib/Analysis/CFG.cpp
+++ b/clang/lib/Analysis/CFG.cpp
@@ -3361,7 +3361,7 @@ CFGBlock *CFGBuilder::VisitGCCAsmStmt(GCCAsmStmt *G, AddStmtChoice asc) {
// Save "Succ" in BackpatchBlocks. In the backpatch processing, "Succ" is
// used to avoid adding "Succ" again.
BackpatchBlocks.push_back(JumpSource(Succ, ScopePos));
- return Block;
+ return VisitChildren(G);
}
CFGBlock *CFGBuilder::VisitForStmt(ForStmt *F) {
diff --git a/clang/lib/Analysis/UninitializedValues.cpp b/clang/lib/Analysis/UninitializedValues.cpp
index a38ae34f4b..811146e50b 100644
--- a/clang/lib/Analysis/UninitializedValues.cpp
+++ b/clang/lib/Analysis/UninitializedValues.cpp
@@ -819,12 +819,11 @@ void TransferFunctions::VisitGCCAsmStmt(GCCAsmStmt *as) {
while (const auto *UO = dyn_cast(Ex))
Ex = stripCasts(C, UO->getSubExpr());
+ // Mark the variable as potentially uninitialized for those cases where
+ // it's used on an indirect path, where it's not guaranteed to be
+ // defined.
if (const VarDecl *VD = findVar(Ex).getDecl())
- if (vals[VD] != Initialized)
- // If the variable isn't initialized by the time we get here, then we
- // mark it as potentially uninitialized for those cases where it's used
- // on an indirect path, where it's not guaranteed to be defined.
- vals[VD] = MayUninitialized;
+ vals[VD] = MayUninitialized;
}
}
diff --git a/clang/lib/Basic/Targets/PPC.cpp b/clang/lib/Basic/Targets/PPC.cpp
index 59656888e2..ecfbe284fb 100644
--- a/clang/lib/Basic/Targets/PPC.cpp
+++ b/clang/lib/Basic/Targets/PPC.cpp
@@ -243,7 +243,10 @@ static void defineXLCompatMacros(MacroBuilder &Builder) {
void PPCTargetInfo::getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
- defineXLCompatMacros(Builder);
+ // We define the XLC compatibility macros only on AIX and Linux since XLC
+ // was never available on any other platforms.
+ if (getTriple().isOSAIX() || getTriple().isOSLinux())
+ defineXLCompatMacros(Builder);
// Target identification.
Builder.defineMacro("__ppc__");
diff --git a/clang/lib/Basic/Targets/Sparc.h b/clang/lib/Basic/Targets/Sparc.h
index 07844abafe..e9f8c10db7 100644
--- a/clang/lib/Basic/Targets/Sparc.h
+++ b/clang/lib/Basic/Targets/Sparc.h
@@ -50,8 +50,6 @@ class LLVM_LIBRARY_VISIBILITY SparcTargetInfo : public TargetInfo {
bool hasFeature(StringRef Feature) const override;
- bool hasSjLjLowering() const override { return true; }
-
ArrayRef getTargetBuiltins() const override {
// FIXME: Implement!
return None;
@@ -180,7 +178,6 @@ class LLVM_LIBRARY_VISIBILITY SparcV8TargetInfo : public SparcTargetInfo {
void getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const override;
- bool hasSjLjLowering() const override { return true; }
bool hasExtIntType() const override { return true; }
};
diff --git a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
index ed8c7e94b0..0e354a49b5 100644
--- a/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/AArch64.cpp
@@ -191,7 +191,7 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
bool success = true;
// Enable NEON by default.
Features.push_back("+neon");
- llvm::StringRef WaMArch = "";
+ llvm::StringRef WaMArch;
if (ForAS)
for (const auto *A :
Args.filtered(options::OPT_Wa_COMMA, options::OPT_Xassembler))
@@ -201,7 +201,7 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
// Call getAArch64ArchFeaturesFromMarch only if "-Wa,-march=" or
// "-Xassembler -march" is detected. Otherwise it may return false
// and causes Clang to error out.
- if (WaMArch.size())
+ if (!WaMArch.empty())
success = getAArch64ArchFeaturesFromMarch(D, WaMArch, Args, Features);
else if ((A = Args.getLastArg(options::OPT_march_EQ)))
success = getAArch64ArchFeaturesFromMarch(D, A->getValue(), Args, Features);
@@ -222,8 +222,15 @@ void aarch64::getAArch64TargetFeatures(const Driver &D,
success = getAArch64MicroArchFeaturesFromMcpu(
D, getAArch64TargetCPU(Args, Triple, A), Args, Features);
- if (!success)
- D.Diag(diag::err_drv_clang_unsupported) << A->getAsString(Args);
+ if (!success) {
+ auto Diag = D.Diag(diag::err_drv_clang_unsupported);
+ // If "-Wa,-march=" is used, 'WaMArch' will contain the argument's value,
+ // while 'A' is uninitialized. Only dereference 'A' in the other case.
+ if (!WaMArch.empty())
+ Diag << "-march=" + WaMArch.str();
+ else
+ Diag << A->getAsString(Args);
+ }
if (Args.getLastArg(options::OPT_mgeneral_regs_only)) {
Features.push_back("-fp-armv8");
diff --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index f04eb91990..4179249e91 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -15868,7 +15868,7 @@ ExprResult Sema::BuildVAArgExpr(SourceLocation BuiltinLoc,
// promoted type and the underlying type are the same except for
// signedness. Ask the AST for the correctly corresponding type and see
// if that's compatible.
- if (!PromoteType.isNull() &&
+ if (!PromoteType.isNull() && !UnderlyingType->isBooleanType() &&
PromoteType->isUnsignedIntegerType() !=
UnderlyingType->isUnsignedIntegerType()) {
UnderlyingType =
diff --git a/lld/CMakeLists.txt b/lld/CMakeLists.txt
index 4c54644c5e..f98acda2be 100644
--- a/lld/CMakeLists.txt
+++ b/lld/CMakeLists.txt
@@ -204,7 +204,6 @@ if (LLVM_INCLUDE_TESTS)
add_subdirectory(unittests)
endif()
-add_subdirectory(docs)
add_subdirectory(COFF)
add_subdirectory(ELF)
add_subdirectory(MachO)
diff --git a/lld/ELF/Arch/PPC.cpp b/lld/ELF/Arch/PPC.cpp
index aaecef6ee9..d9334d5bf8 100644
--- a/lld/ELF/Arch/PPC.cpp
+++ b/lld/ELF/Arch/PPC.cpp
@@ -20,6 +20,9 @@ using namespace llvm::ELF;
using namespace lld;
using namespace lld::elf;
+// Undefine the macro predefined by GCC powerpc32.
+#undef PPC
+
namespace {
class PPC final : public TargetInfo {
public:
diff --git a/lld/docs/AtomLLD.rst b/lld/docs/AtomLLD.rst
deleted file mode 100644
index 2766094696..0000000000
--- a/lld/docs/AtomLLD.rst
+++ /dev/null
@@ -1,62 +0,0 @@
-ATOM-based lld
-==============
-
-Note: this document discuss Mach-O port of LLD. For ELF and COFF,
-see :doc:`index`.
-
-ATOM-based lld is a new set of modular code for creating linker tools.
-Currently it supports Mach-O.
-
-* End-User Features:
-
- * Compatible with existing linker options
- * Reads standard Object Files
- * Writes standard Executable Files
- * Remove clang's reliance on "the system linker"
- * Uses the LLVM `"UIUC" BSD-Style license`__.
-
-* Applications:
-
- * Modular design
- * Support cross linking
- * Easy to add new CPU support
- * Can be built as static tool or library
-
-* Design and Implementation:
-
- * Extensive unit tests
- * Internal linker model can be dumped/read to textual format
- * Additional linking features can be plugged in as "passes"
- * OS specific and CPU specific code factored out
-
-Why a new linker?
------------------
-
-The fact that clang relies on whatever linker tool you happen to have installed
-means that clang has been very conservative adopting features which require a
-recent linker.
-
-In the same way that the MC layer of LLVM has removed clang's reliance on the
-system assembler tool, the lld project will remove clang's reliance on the
-system linker tool.
-
-
-Contents
---------
-
-.. toctree::
- :maxdepth: 2
-
- design
- getting_started
- development
- open_projects
- sphinx_intro
-
-Indices and tables
-------------------
-
-* :ref:`genindex`
-* :ref:`search`
-
-__ https://llvm.org/docs/DeveloperPolicy.html#license
diff --git a/lld/docs/CMakeLists.txt b/lld/docs/CMakeLists.txt
deleted file mode 100644
index 112ce35e8c..0000000000
--- a/lld/docs/CMakeLists.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-if (LLVM_ENABLE_SPHINX)
- include(AddSphinxTarget)
- if (SPHINX_FOUND)
- if (${SPHINX_OUTPUT_HTML})
- add_sphinx_target(html lld)
- endif()
- endif()
-endif()
diff --git a/lld/docs/Driver.rst b/lld/docs/Driver.rst
deleted file mode 100644
index 0ac86ff65f..0000000000
--- a/lld/docs/Driver.rst
+++ /dev/null
@@ -1,82 +0,0 @@
-======
-Driver
-======
-
-Note: this document discuss Mach-O port of LLD. For ELF and COFF,
-see :doc:`index`.
-
-.. contents::
- :local:
-
-Introduction
-============
-
-This document describes the lld driver. The purpose of this document is to
-describe both the motivation and design goals for the driver, as well as details
-of the internal implementation.
-
-Overview
-========
-
-The lld driver is designed to support a number of different command line
-interfaces. The main interfaces we plan to support are binutils' ld, Apple's
-ld, and Microsoft's link.exe.
-
-Flavors
--------
-
-Each of these different interfaces is referred to as a flavor. There is also an
-extra flavor "core" which is used to exercise the core functionality of the
-linker it the test suite.
-
-* gnu
-* darwin
-* link
-* core
-
-Selecting a Flavor
-^^^^^^^^^^^^^^^^^^
-
-There are two different ways to tell lld which flavor to be. They are checked in
-order, so the second overrides the first. The first is to symlink :program:`lld`
-as :program:`lld-{flavor}` or just :program:`{flavor}`. You can also specify
-it as the first command line argument using ``-flavor``::
-
- $ lld -flavor gnu
-
-There is a shortcut for ``-flavor core`` as ``-core``.
-
-
-Adding an Option to an existing Flavor
-======================================
-
-#. Add the option to the desired :file:`lib/Driver/{flavor}Options.td`.
-
-#. Add to :cpp:class:`lld::FlavorLinkingContext` a getter and setter method
- for the option.
-
-#. Modify :cpp:func:`lld::FlavorDriver::parse` in :file:
- `lib/Driver/{Flavor}Driver.cpp` to call the targetInfo setter
- for the option.
-
-#. Modify {Flavor}Reader and {Flavor}Writer to use the new targetInfo option.
-
-
-Adding a Flavor
-===============
-
-#. Add an entry for the flavor in :file:`include/lld/Common/Driver.h` to
- :cpp:class:`lld::UniversalDriver::Flavor`.
-
-#. Add an entry in :file:`lib/Driver/UniversalDriver.cpp` to
- :cpp:func:`lld::Driver::strToFlavor` and
- :cpp:func:`lld::UniversalDriver::link`.
- This allows the flavor to be selected via symlink and `-flavor`.
-
-#. Add a tablegen file called :file:`lib/Driver/{flavor}Options.td` that
- describes the options. If the options are a superset of another driver, that
- driver's td file can simply be included. The :file:`{flavor}Options.td` file
- must also be added to :file:`lib/Driver/CMakeLists.txt`.
-
-#. Add a ``{flavor}Driver`` as a subclass of :cpp:class:`lld::Driver`
- in :file:`lib/Driver/{flavor}Driver.cpp`.
diff --git a/lld/docs/ELF/linker_script.rst b/lld/docs/ELF/linker_script.rst
deleted file mode 100644
index af29996e92..0000000000
--- a/lld/docs/ELF/linker_script.rst
+++ /dev/null
@@ -1,156 +0,0 @@
-Linker Script implementation notes and policy
-=============================================
-
-LLD implements a large subset of the GNU ld linker script notation. The LLD
-implementation policy is to implement linker script features as they are
-documented in the ld `manual `_
-We consider it a bug if the lld implementation does not agree with the manual
-and it is not mentioned in the exceptions below.
-
-The ld manual is not a complete specification, and is not sufficient to build
-an implementation. In particular some features are only defined by the
-implementation and have changed over time.
-
-The lld implementation policy for properties of linker scripts that are not
-defined by the documentation is to follow the GNU ld implementation wherever
-possible. We reserve the right to make different implementation choices where
-it is appropriate for LLD. Intentional deviations will be documented in this
-file.
-
-Symbol assignment
-~~~~~~~~~~~~~~~~~
-
-A symbol assignment looks like:
-
-::
-
- symbol = expression;
- symbol += expression;
-
-The first form defines ``symbol``. If ``symbol`` is already defined, it will be
-overridden. The other form requires ``symbol`` to be already defined.
-
-For a simple assignment like ``alias = aliasee;``, the ``st_type`` field is
-copied from the original symbol. Any arithmetic operation (e.g. ``+ 0`` will
-reset ``st_type`` to ``STT_NOTYPE``.
-
-The ``st_size`` field is set to 0.
-
-SECTIONS command
-~~~~~~~~~~~~~~~~
-
-A ``SECTIONS`` command looks like:
-
-::
-
- SECTIONS {
- section-command
- section-command
- ...
- } [INSERT [AFTER|BEFORE] anchor_section;]
-
-Each section-command can be a symbol assignment, an output section description,
-or an overlay description.
-
-When the ``INSERT`` keyword is present, the ``SECTIONS`` command describes some
-output sections which should be inserted after or before the specified anchor
-section. The insertion occurs after input sections have been mapped to output
-sections but before orphan sections have been processed.
-
-In the case where no linker script has been provided or every ``SECTIONS``
-command is followed by ``INSERT``, LLD applies built-in rules which are similar
-to GNU ld's internal linker scripts.
-
-- Align the first section in a ``PT_LOAD`` segment according to ``-z noseparate-code``,
- ``-z separate-code``, or ``-z separate-loadable-segments``
-- Define ``__bss_start``, ``end``, ``_end``, ``etext``, ``_etext``, ``edata``, ``_edata``
-- Sort ``.ctors.*``/``.dtors.*``/``.init_array.*``/``.fini_array.*`` and PowerPC64 specific ``.toc``
-- Place input ``.text.*`` into output ``.text``, and handle certain variants
- (``.text.hot.``, ``.text.unknown.``, ``.text.unlikely.``, etc) in the precense of
- ``-z keep-text-section-prefix``.
-
-Output section description
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The description of an output section looks like:
-
-::
-
- section [address] [(type)] : [AT(lma)] [ALIGN(section_align)] [SUBALIGN](subsection_align)] {
- output-section-command
- ...
- } [>region] [AT>lma_region] [:phdr ...] [=fillexp] [,]
-
-Output section address
-----------------------
-
-When an *OutputSection* *S* has ``address``, LLD will set sh_addr to ``address``.
-
-The ELF specification says:
-
-> The value of sh_addr must be congruent to 0, modulo the value of sh_addralign.
-
-The presence of ``address`` can cause the condition unsatisfied. LLD will warn.
-GNU ld from Binutils 2.35 onwards will reduce sh_addralign so that
-sh_addr=0 (modulo sh_addralign).
-
-Output section alignment
-------------------------
-
-sh_addralign of an *OutputSection* *S* is the maximum of
-``ALIGN(section_align)`` and the maximum alignment of the input sections in
-*S*.
-
-When an *OutputSection* *S* has both ``address`` and ``ALIGN(section_align)``,
-GNU ld will set sh_addralign to ``ALIGN(section_align)``.
-
-Output section LMA
-------------------
-
-A load address (LMA) can be specified by ``AT(lma)`` or ``AT>lma_region``.
-
-- ``AT(lma)`` specifies the exact load address. If the linker script does not
- have a PHDRS command, then a new loadable segment will be generated.
-- ``AT>lma_region`` specifies the LMA region. The lack of ``AT>lma_region``
- means the default region is used. Note, GNU ld propagates the previous LMA
- memory region when ``address`` is not specified. The LMA is set to the
- current location of the memory region aligned to the section alignment.
- If the linker script does not have a PHDRS command, then if
- ``lma_region`` is different from the ``lma_region`` for
- the previous OutputSection a new loadable segment will be generated.
-
-The two keywords cannot be specified at the same time.
-
-If neither ``AT(lma)`` nor ``AT>lma_region`` is specified:
-
-- If the previous section is also in the default LMA region, and the two
- section have the same memory regions, the difference between the LMA and the
- VMA is computed to be the same as the previous difference.
-- Otherwise, the LMA is set to the VMA.
-
-Overwrite sections
-~~~~~~~~~~~~~~~~~~
-
-An ``OVERWRITE_SECTIONS`` command looks like:
-
-::
-
- OVERWRITE_SECTIONS {
- output-section-description
- output-section-description
- ...
- }
-
-Unlike a ``SECTIONS`` command, ``OVERWRITE_SECTIONS`` does not specify a
-section order or suppress the built-in rules.
-
-If a described output section description also appears in a ``SECTIONS``
-command, the ``OVERWRITE_SECTIONS`` command wins; otherwise, the output section
-will be added somewhere following the usual orphan section placement rules.
-
-If a described output section description also appears in an ``INSERT
-[AFTER|BEFORE]`` command, the description will be provided by the
-description in the ``OVERWRITE_SECTIONS`` command while the insert command
-still applies (possibly after orphan section placement). It is recommended to
-leave the brace empty (i.e. ``section : {}``) for the insert command, because
-its description will be ignored anyway.
diff --git a/lld/docs/ELF/warn_backrefs.rst b/lld/docs/ELF/warn_backrefs.rst
deleted file mode 100644
index fac2145cc0..0000000000
--- a/lld/docs/ELF/warn_backrefs.rst
+++ /dev/null
@@ -1,99 +0,0 @@
---warn-backrefs
-===============
-
-``--warn-backrefs`` gives a warning when an undefined symbol reference is
-resolved by a definition in an archive to the left of it on the command line.
-
-A linker such as GNU ld makes a single pass over the input files from left to
-right maintaining the set of undefined symbol references from the files loaded
-so far. When encountering an archive or an object file surrounded by
-``--start-lib`` and ``--end-lib`` that archive will be searched for resolving
-symbol definitions; this may result in input files being loaded, updating the
-set of undefined symbol references. When all resolving definitions have been
-loaded from the archive, the linker moves on the next file and will not return
-to it. This means that if an input file to the right of a archive cannot have
-an undefined symbol resolved by a archive to the left of it. For example:
-
- ld def.a ref.o
-
-will result in an ``undefined reference`` error. If there are no cyclic
-references, the archives can be ordered in such a way that there are no
-backward references. If there are cyclic references then the ``--start-group``
-and ``--end-group`` options can be used, or the same archive can be placed on
-the command line twice.
-
-LLD remembers the symbol table of archives that it has previously seen, so if
-there is a reference from an input file to the right of an archive, LLD will
-still search that archive for resolving any undefined references. This means
-that an archive only needs to be included once on the command line and the
-``--start-group`` and ``--end-group`` options are redundant.
-
-A consequence of the differing archive searching semantics is that the same
-linker command line can result in different outcomes. A link may succeed with
-LLD that will fail with GNU ld, or even worse both links succeed but they have
-selected different objects from different archives that both define the same
-symbols.
-
-The ``warn-backrefs`` option provides information that helps identify cases
-where LLD and GNU ld archive selection may differ.
-
- | % ld.lld --warn-backrefs ... -lB -lA
- | ld.lld: warning: backward reference detected: system in A.a(a.o) refers to B.a(b.o)
-
- | % ld.lld --warn-backrefs ... --start-lib B/b.o --end-lib --start-lib A/a.o --end-lib
- | ld.lld: warning: backward reference detected: system in A/a.o refers to B/b.o
-
- # To suppress the warning, you can specify --warn-backrefs-exclude= to match B/b.o or B.a(b.o)
-
-The ``--warn-backrefs`` option can also provide a check to enforce a
-topological order of archives, which can be useful to detect layering
-violations (albeit unable to catch all cases). There are two cases where GNU ld
-will result in an ``undefined reference`` error:
-
-* If adding the dependency does not form a cycle: conceptually ``A`` is higher
- level library while ``B`` is at a lower level. When you are developing an
- application ``P`` which depends on ``A``, but does not directly depend on
- ``B``, your link may fail surprisingly with ``undefined symbol:
- symbol_defined_in_B`` if the used/linked part of ``A`` happens to need some
- components of ``B``. It is inappropriate for ``P`` to add a dependency on
- ``B`` since ``P`` does not use ``B`` directly.
-* If adding the dependency forms a cycle, e.g. ``B->C->A ~> B``. ``A``
- is supposed to be at the lowest level while ``B`` is supposed to be at the
- highest level. When you are developing ``C_test`` testing ``C``, your link may
- fail surprisingly with ``undefined symbol`` if there is somehow a dependency on
- some components of ``B``. You could fix the issue by adding the missing
- dependency (``B``), however, then every test (``A_test``, ``B_test``,
- ``C_test``) will link against every library. This breaks the motivation
- of splitting ``B``, ``C`` and ``A`` into separate libraries and makes binaries
- unnecessarily large. Moreover, the layering violation makes lower-level
- libraries (e.g. ``A``) vulnerable to changes to higher-level libraries (e.g.
- ``B``, ``C``).
-
-Resolution:
-
-* Add a dependency from ``A`` to ``B``.
-* The reference may be unintended and can be removed.
-* The dependency may be intentionally omitted because there are multiple
- libraries like ``B``. Consider linking ``B`` with object semantics by
- surrounding it with ``--whole-archive`` and ``--no-whole-archive``.
-* In the case of circular dependency, sometimes merging the libraries are the best.
-
-There are two cases like a library sandwich where GNU ld will select a
-different object.
-
-* ``A.a B A2.so``: ``A.a`` may be used as an interceptor (e.g. it provides some
- optimized libc functions and ``A2`` is libc). ``B`` does not need to know
- about ``A.a``, and ``A.a`` may be pulled into the link by other part of the
- program. For linker portability, consider ``--whole-archive`` and
- ``--no-whole-archive``.
-
-* ``A.a B A2.a``: similar to the above case but ``--warn-backrefs`` does not
- flag the problem, because ``A2.a`` may be a replicate of ``A.a``, which is
- redundant but benign. In some cases ``A.a`` and ``B`` should be surrounded by
- a pair of ``--start-group`` and ``--end-group``. This is especially common
- among system libraries (e.g. ``-lc __isnanl references -lm``, ``-lc
- _IO_funlockfile references -lpthread``, ``-lc __gcc_personality_v0 references
- -lgcc_eh``, and ``-lpthread _Unwind_GetCFA references -lunwind``).
-
- In C++, this is likely an ODR violation. We probably need a dedicated option
- for ODR detection.
diff --git a/lld/docs/NewLLD.rst b/lld/docs/NewLLD.rst
deleted file mode 100644
index 1b1c87067f..0000000000
--- a/lld/docs/NewLLD.rst
+++ /dev/null
@@ -1,317 +0,0 @@
-The ELF, COFF and Wasm Linkers
-==============================
-
-The ELF Linker as a Library
----------------------------
-
-You can embed LLD to your program by linking against it and calling the linker's
-entry point function lld::elf::link.
-
-The current policy is that it is your responsibility to give trustworthy object
-files. The function is guaranteed to return as long as you do not pass corrupted
-or malicious object files. A corrupted file could cause a fatal error or SEGV.
-That being said, you don't need to worry too much about it if you create object
-files in the usual way and give them to the linker. It is naturally expected to
-work, or otherwise it's a linker's bug.
-
-Design
-======
-
-We will describe the design of the linkers in the rest of the document.
-
-Key Concepts
-------------
-
-Linkers are fairly large pieces of software.
-There are many design choices you have to make to create a complete linker.
-
-This is a list of design choices we've made for ELF and COFF LLD.
-We believe that these high-level design choices achieved a right balance
-between speed, simplicity and extensibility.
-
-* Implement as native linkers
-
- We implemented the linkers as native linkers for each file format.
-
- The linkers share the same design but share very little code.
- Sharing code makes sense if the benefit is worth its cost.
- In our case, the object formats are different enough that we thought the layer
- to abstract the differences wouldn't be worth its complexity and run-time
- cost. Elimination of the abstract layer has greatly simplified the
- implementation.
-
-* Speed by design
-
- One of the most important things in archiving high performance is to
- do less rather than do it efficiently.
- Therefore, the high-level design matters more than local optimizations.
- Since we are trying to create a high-performance linker,
- it is very important to keep the design as efficient as possible.
-
- Broadly speaking, we do not do anything until we have to do it.
- For example, we do not read section contents or relocations
- until we need them to continue linking.
- When we need to do some costly operation (such as looking up
- a hash table for each symbol), we do it only once.
- We obtain a handle (which is typically just a pointer to actual data)
- on the first operation and use it throughout the process.
-
-* Efficient archive file handling
-
- LLD's handling of archive files (the files with ".a" file extension) is
- different from the traditional Unix linkers and similar to Windows linkers.
- We'll describe how the traditional Unix linker handles archive files, what the
- problem is, and how LLD approached the problem.
-
- The traditional Unix linker maintains a set of undefined symbols during
- linking. The linker visits each file in the order as they appeared in the
- command line until the set becomes empty. What the linker would do depends on
- file type.
-
- - If the linker visits an object file, the linker links object files to the
- result, and undefined symbols in the object file are added to the set.
-
- - If the linker visits an archive file, it checks for the archive file's
- symbol table and extracts all object files that have definitions for any
- symbols in the set.
-
- This algorithm sometimes leads to a counter-intuitive behavior. If you give
- archive files before object files, nothing will happen because when the linker
- visits archives, there is no undefined symbols in the set. As a result, no
- files are extracted from the first archive file, and the link is done at that
- point because the set is empty after it visits one file.
-
- You can fix the problem by reordering the files,
- but that cannot fix the issue of mutually-dependent archive files.
-
- Linking mutually-dependent archive files is tricky. You may specify the same
- archive file multiple times to let the linker visit it more than once. Or,
- you may use the special command line options, `--start-group` and
- `--end-group`, to let the linker loop over the files between the options until
- no new symbols are added to the set.
-
- Visiting the same archive files multiple times makes the linker slower.
-
- Here is how LLD approaches the problem. Instead of memorizing only undefined
- symbols, we program LLD so that it memorizes all symbols. When it sees an
- undefined symbol that can be resolved by extracting an object file from an
- archive file it previously visited, it immediately extracts the file and links
- it. It is doable because LLD does not forget symbols it has seen in archive
- files.
-
- We believe that LLD's way is efficient and easy to justify.
-
- The semantics of LLD's archive handling are different from the traditional
- Unix's. You can observe it if you carefully craft archive files to exploit
- it. However, in reality, we don't know any program that cannot link with our
- algorithm so far, so it's not going to cause trouble.
-
-Numbers You Want to Know
-------------------------
-
-To give you intuition about what kinds of data the linker is mainly working on,
-I'll give you the list of objects and their numbers LLD has to read and process
-in order to link a very large executable. In order to link Chrome with debug
-info, which is roughly 2 GB in output size, LLD reads
-
-- 17,000 files,
-- 1,800,000 sections,
-- 6,300,000 symbols, and
-- 13,000,000 relocations.
-
-LLD produces the 2 GB executable in 15 seconds.
-
-These numbers vary depending on your program, but in general,
-you have a lot of relocations and symbols for each file.
-If your program is written in C++, symbol names are likely to be
-pretty long because of name mangling.
-
-It is important to not waste time on relocations and symbols.
-
-In the above case, the total amount of symbol strings is 450 MB,
-and inserting all of them to a hash table takes 1.5 seconds.
-Therefore, if you causally add a hash table lookup for each symbol,
-it would slow down the linker by 10%. So, don't do that.
-
-On the other hand, you don't have to pursue efficiency
-when handling files.
-
-Important Data Structures
--------------------------
-
-We will describe the key data structures in LLD in this section. The linker can
-be understood as the interactions between them. Once you understand their
-functions, the code of the linker should look obvious to you.
-
-* Symbol
-
- This class represents a symbol.
- They are created for symbols in object files or archive files.
- The linker creates linker-defined symbols as well.
-
- There are basically three types of Symbols: Defined, Undefined, or Lazy.
-
- - Defined symbols are for all symbols that are considered as "resolved",
- including real defined symbols, COMDAT symbols, common symbols,
- absolute symbols, linker-created symbols, etc.
- - Undefined symbols represent undefined symbols, which need to be replaced by
- Defined symbols by the resolver until the link is complete.
- - Lazy symbols represent symbols we found in archive file headers
- which can turn into Defined if we read archive members.
-
- There's only one Symbol instance for each unique symbol name. This uniqueness
- is guaranteed by the symbol table. As the resolver reads symbols from input
- files, it replaces an existing Symbol with the "best" Symbol for its symbol
- name using the placement new.
-
- The above mechanism allows you to use pointers to Symbols as a very cheap way
- to access name resolution results. Assume for example that you have a pointer
- to an undefined symbol before name resolution. If the symbol is resolved to a
- defined symbol by the resolver, the pointer will "automatically" point to the
- defined symbol, because the undefined symbol the pointer pointed to will have
- been replaced by the defined symbol in-place.
-
-* SymbolTable
-
- SymbolTable is basically a hash table from strings to Symbols
- with logic to resolve symbol conflicts. It resolves conflicts by symbol type.
-
- - If we add Defined and Undefined symbols, the symbol table will keep the
- former.
- - If we add Defined and Lazy symbols, it will keep the former.
- - If we add Lazy and Undefined, it will keep the former,
- but it will also trigger the Lazy symbol to load the archive member
- to actually resolve the symbol.
-
-* Chunk (COFF specific)
-
- Chunk represents a chunk of data that will occupy space in an output.
- Each regular section becomes a chunk.
- Chunks created for common or BSS symbols are not backed by sections.
- The linker may create chunks to append additional data to an output as well.
-
- Chunks know about their size, how to copy their data to mmap'ed outputs,
- and how to apply relocations to them.
- Specifically, section-based chunks know how to read relocation tables
- and how to apply them.
-
-* InputSection (ELF specific)
-
- Since we have less synthesized data for ELF, we don't abstract slices of
- input files as Chunks for ELF. Instead, we directly use the input section
- as an internal data type.
-
- InputSection knows about their size and how to copy themselves to
- mmap'ed outputs, just like COFF Chunks.
-
-* OutputSection
-
- OutputSection is a container of InputSections (ELF) or Chunks (COFF).
- An InputSection or Chunk belongs to at most one OutputSection.
-
-There are mainly three actors in this linker.
-
-* InputFile
-
- InputFile is a superclass of file readers.
- We have a different subclass for each input file type,
- such as regular object file, archive file, etc.
- They are responsible for creating and owning Symbols and InputSections/Chunks.
-
-* Writer
-
- The writer is responsible for writing file headers and InputSections/Chunks to
- a file. It creates OutputSections, put all InputSections/Chunks into them,
- assign unique, non-overlapping addresses and file offsets to them, and then
- write them down to a file.
-
-* Driver
-
- The linking process is driven by the driver. The driver:
-
- - processes command line options,
- - creates a symbol table,
- - creates an InputFile for each input file and puts all symbols within into
- the symbol table,
- - checks if there's no remaining undefined symbols,
- - creates a writer,
- - and passes the symbol table to the writer to write the result to a file.
-
-Link-Time Optimization
-----------------------
-
-LTO is implemented by handling LLVM bitcode files as object files.
-The linker resolves symbols in bitcode files normally. If all symbols
-are successfully resolved, it then runs LLVM passes
-with all bitcode files to convert them to one big regular ELF/COFF file.
-Finally, the linker replaces bitcode symbols with ELF/COFF symbols,
-so that they are linked as if they were in the native format from the beginning.
-
-The details are described in this document.
-https://llvm.org/docs/LinkTimeOptimization.html
-
-Glossary
---------
-
-* RVA (COFF)
-
- Short for Relative Virtual Address.
-
- Windows executables or DLLs are not position-independent; they are
- linked against a fixed address called an image base. RVAs are
- offsets from an image base.
-
- Default image bases are 0x140000000 for executables and 0x18000000
- for DLLs. For example, when we are creating an executable, we assume
- that the executable will be loaded at address 0x140000000 by the
- loader, so we apply relocations accordingly. Result texts and data
- will contain raw absolute addresses.
-
-* VA
-
- Short for Virtual Address. For COFF, it is equivalent to RVA + image base.
-
-* Base relocations (COFF)
-
- Relocation information for the loader. If the loader decides to map
- an executable or a DLL to a different address than their image
- bases, it fixes up binaries using information contained in the base
- relocation table. A base relocation table consists of a list of
- locations containing addresses. The loader adds a difference between
- RVA and actual load address to all locations listed there.
-
- Note that this run-time relocation mechanism is much simpler than ELF.
- There's no PLT or GOT. Images are relocated as a whole just
- by shifting entire images in memory by some offsets. Although doing
- this breaks text sharing, I think this mechanism is not actually bad
- on today's computers.
-
-* ICF
-
- Short for Identical COMDAT Folding (COFF) or Identical Code Folding (ELF).
-
- ICF is an optimization to reduce output size by merging read-only sections
- by not only their names but by their contents. If two read-only sections
- happen to have the same metadata, actual contents and relocations,
- they are merged by ICF. It is known as an effective technique,
- and it usually reduces C++ program's size by a few percent or more.
-
- Note that this is not an entirely sound optimization. C/C++ require
- different functions have different addresses. If a program depends on
- that property, it would fail at runtime.
-
- On Windows, that's not really an issue because MSVC link.exe enabled
- the optimization by default. As long as your program works
- with the linker's default settings, your program should be safe with ICF.
-
- On Unix, your program is generally not guaranteed to be safe with ICF,
- although large programs happen to work correctly.
- LLD works fine with ICF for example.
-
-Other Info
-----------
-
-.. toctree::
- :maxdepth: 1
-
- missingkeyfunction
diff --git a/lld/docs/Partitions.rst b/lld/docs/Partitions.rst
deleted file mode 100644
index e911308763..0000000000
--- a/lld/docs/Partitions.rst
+++ /dev/null
@@ -1,116 +0,0 @@
-Partitions
-==========
-
-.. warning::
-
- This feature is currently experimental, and its interface is subject
- to change.
-
-LLD's partitioning feature allows a program (which may be an executable
-or a shared library) to be split into multiple pieces, or partitions. A
-partitioned program consists of a main partition together with a number of
-loadable partitions. The loadable partitions depend on the main partition
-in a similar way to a regular ELF shared object dependency, but unlike a
-shared object, the main partition and the loadable partitions share a virtual
-address space at link time, and each loadable partition is assigned a fixed
-offset from the main partition. This allows the loadable partitions to refer
-to code and data in the main partition directly without the binary size and
-performance overhead of PLTs, GOTs or symbol table entries.
-
-Usage
------
-
-A program that uses the partitioning feature must decide which symbols are
-going to be used as the "entry points" for each partition. An entry point
-could, for example, be the equivalent of the partition's ``main`` function, or
-there could be a group of functions that expose the functionality implemented
-by the partition. The intent is that in order to use a loadable partition,
-the program will use ``dlopen``/``dlsym`` or similar functions to dynamically
-load the partition at its assigned address, look up an entry point by name
-and call it. Note, however, that the standard ``dlopen`` function does not
-allow specifying a load address. On Android, the ``android_dlopen_ext``
-function may be used together with the ``ANDROID_DLEXT_RESERVED_ADDRESS``
-flag to load a shared object at a specific address.
-
-Once the entry points have been decided, the translation unit(s)
-containing the entry points should be compiled using the Clang compiler flag
-``-fsymbol-partition=``, where ```` is the intended soname
-of the partition. The resulting object files are passed to the linker in
-the usual way.
-
-The linker will then use these entry points to automatically split the program
-into partitions according to which sections of the program are reachable from
-which entry points, similarly to how ``--gc-sections`` removes unused parts of
-a program. Any sections that are only reachable from a loadable partition's
-entry point are assigned to that partition, while all other sections are
-assigned to the main partition, including sections only reachable from
-loadable partitions.
-
-The following diagram illustrates how sections are assigned to partitions. Each
-section is colored according to its assigned partition.
-
-.. image:: partitions.svg
-
-The result of linking a program that uses partitions is essentially an
-ELF file with all of the partitions concatenated together. This file is
-referred to as a combined output file. To extract a partition from the
-combined output file, the ``llvm-objcopy`` tool should be used together
-with the flag ``--extract-main-partition`` to extract the main partition, or
-``-extract-partition=`` to extract one of the loadable partitions.
-An example command sequence is shown below:
-
-.. code-block:: shell
-
- # Compile the main program.
- clang -ffunction-sections -fdata-sections -c main.c
-
- # Compile a feature to be placed in a loadable partition.
- # Note that this is likely to be a separate build step to the main partition.
- clang -ffunction-sections -fdata-sections -fsymbol-partition=libfeature.so -c feature.c
-
- # Link the combined output file.
- clang main.o feature.o -fuse-ld=lld -shared -o libcombined.so -Wl,-soname,libmain.so -Wl,--gc-sections
-
- # Extract the partitions.
- llvm-objcopy libcombined.so libmain.so --extract-main-partition
- llvm-objcopy libcombined.so libfeature.so --extract-partition=libfeature.so
-
-In order to allow a program to discover the names of its loadable partitions
-and the locations of their reserved regions, the linker creates a partition
-index, which is an array of structs with the following definition:
-
-.. code-block:: c
-
- struct partition_index_entry {
- int32_t name_offset;
- int32_t addr_offset;
- uint32_t size;
- };
-
-The ``name_offset`` field is a relative pointer to a null-terminated string
-containing the soname of the partition, the ``addr_offset`` field is a
-relative pointer to its load address and the ``size`` field contains the
-size of the region reserved for the partition. To derive an absolute pointer
-from the relative pointer fields in this data structure, the address of the
-field should be added to the value stored in the field.
-
-The program may discover the location of the partition index using the
-linker-defined symbols ``__part_index_begin`` and ``__part_index_end``.
-
-Restrictions
-------------
-
-This feature is currently only supported in the ELF linker.
-
-The partitioning feature may not currently be used together with the
-``SECTIONS`` or ``PHDRS`` linker script features, nor may it be used with the
-``--section-start``, ``-Ttext``, ``-Tdata`` or ``-Tbss`` flags. All of these
-features assume a single set of output sections and/or program headers, which
-makes their semantics ambiguous in the presence of more than one partition.
-
-The partitioning feature may not currently be used on the MIPS architecture
-because it is unclear whether the MIPS multi-GOT ABI is compatible with
-partitions.
-
-The current implementation only supports creating up to 254 partitions due
-to implementation limitations. This limit may be relaxed in the future.
diff --git a/lld/docs/README.txt b/lld/docs/README.txt
deleted file mode 100644
index 2ed016639d..0000000000
--- a/lld/docs/README.txt
+++ /dev/null
@@ -1,9 +0,0 @@
-lld Documentation
-=================
-
-The lld documentation is written using the Sphinx documentation generator. It is
-currently tested with Sphinx 1.1.3.
-
-We currently use the 'nature' theme and a Beaker inspired structure.
-
-See sphinx_intro.rst for more details.
diff --git a/lld/docs/Readers.rst b/lld/docs/Readers.rst
deleted file mode 100644
index eae1717f6e..0000000000
--- a/lld/docs/Readers.rst
+++ /dev/null
@@ -1,174 +0,0 @@
-.. _Readers:
-
-Developing lld Readers
-======================
-
-Note: this document discuss Mach-O port of LLD. For ELF and COFF,
-see :doc:`index`.
-
-Introduction
-------------
-
-The purpose of a "Reader" is to take an object file in a particular format
-and create an `lld::File`:cpp:class: (which is a graph of Atoms)
-representing the object file. A Reader inherits from
-`lld::Reader`:cpp:class: which lives in
-:file:`include/lld/Core/Reader.h` and
-:file:`lib/Core/Reader.cpp`.
-
-The Reader infrastructure for an object format ``Foo`` requires the
-following pieces in order to fit into lld:
-
-:file:`include/lld/ReaderWriter/ReaderFoo.h`
-
- .. cpp:class:: ReaderOptionsFoo : public ReaderOptions
-
- This Options class is the only way to configure how the Reader will
- parse any file into an `lld::Reader`:cpp:class: object. This class
- should be declared in the `lld`:cpp:class: namespace.
-
- .. cpp:function:: Reader *createReaderFoo(ReaderOptionsFoo &reader)
-
- This factory function configures and create the Reader. This function
- should be declared in the `lld`:cpp:class: namespace.
-
-:file:`lib/ReaderWriter/Foo/ReaderFoo.cpp`
-
- .. cpp:class:: ReaderFoo : public Reader
-
- This is the concrete Reader class which can be called to parse
- object files. It should be declared in an anonymous namespace or
- if there is shared code with the `lld::WriterFoo`:cpp:class: you
- can make a nested namespace (e.g. `lld::foo`:cpp:class:).
-
-You may have noticed that :cpp:class:`ReaderFoo` is not declared in the
-``.h`` file. An important design aspect of lld is that all Readers are
-created *only* through an object-format-specific
-:cpp:func:`createReaderFoo` factory function. The creation of the Reader is
-parametrized through a :cpp:class:`ReaderOptionsFoo` class. This options
-class is the one-and-only way to control how the Reader operates when
-parsing an input file into an Atom graph. For instance, you may want the
-Reader to only accept certain architectures. The options class can be
-instantiated from command line options or be programmatically configured.
-
-Where to start
---------------
-
-The lld project already has a skeleton of source code for Readers for
-``ELF``, ``PECOFF``, ``MachO``, and lld's native ``YAML`` graph format.
-If your file format is a variant of one of those, you should modify the
-existing Reader to support your variant. This is done by customizing the Options
-class for the Reader and making appropriate changes to the ``.cpp`` file to
-interpret those options and act accordingly.
-
-If your object file format is not a variant of any existing Reader, you'll need
-to create a new Reader subclass with the organization described above.
-
-Readers are factories
----------------------
-
-The linker will usually only instantiate your Reader once. That one Reader will
-have its loadFile() method called many times with different input files.
-To support multithreaded linking, the Reader may be parsing multiple input
-files in parallel. Therefore, there should be no parsing state in you Reader
-object. Any parsing state should be in ivars of your File subclass or in
-some temporary object.
-
-The key function to implement in a reader is::
-
- virtual error_code loadFile(LinkerInput &input,
- std::vector> &result);
-
-It takes a memory buffer (which contains the contents of the object file
-being read) and returns an instantiated lld::File object which is
-a collection of Atoms. The result is a vector of File pointers (instead of
-simple a File pointer) because some file formats allow multiple object
-"files" to be encoded in one file system file.
-
-
-Memory Ownership
-----------------
-
-Atoms are always owned by their File object. During core linking when Atoms
-are coalesced or stripped away, core linking does not delete them.
-Core linking just removes those unused Atoms from its internal list.
-The destructor of a File object is responsible for deleting all Atoms it
-owns, and if ownership of the MemoryBuffer was passed to it, the File
-destructor needs to delete that too.
-
-Making Atoms
-------------
-
-The internal model of lld is purely Atom based. But most object files do not
-have an explicit concept of Atoms, instead most have "sections". The way
-to think of this is that a section is just a list of Atoms with common
-attributes.
-
-The first step in parsing section-based object files is to cleave each
-section into a list of Atoms. The technique may vary by section type. For
-code sections (e.g. .text), there are usually symbols at the start of each
-function. Those symbol addresses are the points at which the section is
-cleaved into discrete Atoms. Some file formats (like ELF) also include the
-length of each symbol in the symbol table. Otherwise, the length of each
-Atom is calculated to run to the start of the next symbol or the end of the
-section.
-
-Other sections types can be implicitly cleaved. For instance c-string literals
-or unwind info (e.g. .eh_frame) can be cleaved by having the Reader look at
-the content of the section. It is important to cleave sections into Atoms
-to remove false dependencies. For instance the .eh_frame section often
-has no symbols, but contains "pointers" to the functions for which it
-has unwind info. If the .eh_frame section was not cleaved (but left as one
-big Atom), there would always be a reference (from the eh_frame Atom) to
-each function. So the linker would be unable to coalesce or dead stripped
-away the function atoms.
-
-The lld Atom model also requires that a reference to an undefined symbol be
-modeled as a Reference to an UndefinedAtom. So the Reader also needs to
-create an UndefinedAtom for each undefined symbol in the object file.
-
-Once all Atoms have been created, the second step is to create References
-(recall that Atoms are "nodes" and References are "edges"). Most References
-are created by looking at the "relocation records" in the object file. If
-a function contains a call to "malloc", there is usually a relocation record
-specifying the address in the section and the symbol table index. Your
-Reader will need to convert the address to an Atom and offset and the symbol
-table index into a target Atom. If "malloc" is not defined in the object file,
-the target Atom of the Reference will be an UndefinedAtom.
-
-
-Performance
------------
-Once you have the above working to parse an object file into Atoms and
-References, you'll want to look at performance. Some techniques that can
-help performance are:
-
-* Use llvm::BumpPtrAllocator or pre-allocate one big vector and then
- just have each atom point to its subrange of References in that vector.
- This can be faster that allocating each Reference as separate object.
-* Pre-scan the symbol table and determine how many atoms are in each section
- then allocate space for all the Atom objects at once.
-* Don't copy symbol names or section content to each Atom, instead use
- StringRef and ArrayRef in each Atom to point to its name and content in the
- MemoryBuffer.
-
-
-Testing
--------
-
-We are still working on infrastructure to test Readers. The issue is that
-you don't want to check in binary files to the test suite. And the tools
-for creating your object file from assembly source may not be available on
-every OS.
-
-We are investigating a way to use YAML to describe the section, symbols,
-and content of a file. Then have some code which will write out an object
-file from that YAML description.
-
-Once that is in place, you can write test cases that contain section/symbols
-YAML and is run through the linker to produce Atom/References based YAML which
-is then run through FileCheck to verify the Atoms and References are as
-expected.
-
-
-
diff --git a/lld/docs/ReleaseNotes.rst b/lld/docs/ReleaseNotes.rst
deleted file mode 100644
index 238bf5a9f6..0000000000
--- a/lld/docs/ReleaseNotes.rst
+++ /dev/null
@@ -1,188 +0,0 @@
-========================
-lld 13.0.0 Release Notes
-========================
-
-.. contents::
- :local:
-
-Introduction
-============
-
-This document contains the release notes for the lld linker, release 13.0.0.
-Here we describe the status of lld, including major improvements
-from the previous release. All lld releases may be downloaded
-from the `LLVM releases web site `_.
-
-Non-comprehensive list of changes in this release
-=================================================
-
-ELF Improvements
-----------------
-
-* ``-z start-stop-gc`` is now supported and becomes the default.
- (`D96914 `_)
- (`rG6d2d3bd0 `_)
-* ``--shuffle-sections=`` has been changed to ``--shuffle-sections==``.
- If seed is -1, the matched input sections are reversed.
- (`D98445 `_)
- (`D98679 `_)
-* ``-Bsymbolic -Bsymbolic-functions`` has been changed to behave the same as ``-Bsymbolic-functions``. This matches GNU ld.
- (`D102461 `_)
-* ``-Bno-symbolic`` has been added.
- (`D102461 `_)
-* A new linker script command ``OVERWRITE_SECTIONS`` has been added.
- (`D103303 `_)
-* ``-Bsymbolic-non-weak-functions`` has been added as a ``STB_GLOBAL`` subset of ``-Bsymbolic-functions``.
- (`D102570 `_)
-* ``--no-allow-shlib-undefined`` has been improved to catch more cases.
- (`D101996 `_)
-* ``__rela_iplt_start`` is no longer defined for -pie/-shared.
- This makes GCC/Clang ``-static-pie`` built executables work.
- (`rG8cb78e99 `_)
-* IRELATIVE/TLSDESC relocations now support ``-z rel``.
- (`D100544 `_)
-* Section groups with a zero flag are now supported.
- This is used by ``comdat nodeduplicate`` in LLVM IR.
- (`D96636 `_)
- (`D106228 `_)
-* Defined symbols are now resolved before undefined symbols to stabilize the bheavior of archive member extraction.
- (`D95985 `_)
-* ``STB_WEAK`` symbols are now preferred over COMMON symbols as a fix to a ``--fortran-common`` regression.
- (`D105945 `_)
-* Absolute relocations referencing undef weak now produce dynamic relocations for -pie, matching GOT-generating relocations.
- (`D105164 `_)
-* Exported symbols are now communicated to the LTO library so as to make LTO
- based whole program devirtualization (``-flto=thin -fwhole-program-vtables``)
- work with shared objects.
- (`D91583 `_)
-* Whole program devirtualization now respects ``local:`` version nodes in a version script.
- (`D98220 `_)
- (`D98686 `_)
-* ``local:`` version nodes in a version script now apply to non-default version symbols.
- (`D107234 `_)
-* If an object file defines both ``foo`` and ``foo@v1``, now only ``foo@v1`` will be in the output.
- (`D107235 `_)
-* Copy relocations on non-default version symbols are now supported.
- (`D107535 `_)
-
-Linker script changes:
-
-* ``.``, ``$``, and double quotes can now be used in symbol names in expressions.
- (`D98306 `_)
- (`rGe7a7ad13 `_)
-* Fixed value of ``.`` in the output section description of ``.tbss``.
- (`D107288 `_)
-* ``NOLOAD`` sections can now be placed in a ``PT_LOAD`` program header.
- (`D103815 `_)
-* ``OUTPUT_FORMAT(default, big, little)`` now consults ``-EL`` and ``-EB``.
- (`D96214 `_)
-* The ``OVERWRITE_SECTIONS`` command has been added.
- (`D103303 `_)
-* The section order within an ``INSERT AFTER`` command is now preserved.
- (`D105158 `_)
-
-Architecture specific changes:
-
-* aarch64_be is now supported.
- (`D96188 `_)
-* The AMDGPU port now supports ``--amdhsa-code-object-version=4`` object files;
- (`D95811 `_)
-* The ARM port now accounts for PC biases in range extension thunk creation.
- (`D97550 `_)
-* The AVR port now computes ``e_flags``.
- (`D99754 `_)
-* The Mips port now omits unneeded dynamic relocations for PIE non-preemptible TLS.
- (`D101382 `_)
-* The PowerPC port now supports ``--power10-stubs=no`` to omit Power10 instructions from call stubs.
- (`D94625 `_)
-* Fixed a thunk creation bug in the PowerPC port when TOC/NOTOC calls are mixed.
- (`D101837 `_)
-* The RISC-V port now resolves undefined weak relocations to the current location if not using PLT.
- (`D103001 `_)
-* ``R_386_GOTOFF`` relocations from .debug_info are now allowed to be compatible with GCC.
- (`D95994 `_)
-* ``gotEntrySize`` has been added to improve support for the ILP32 ABI of x86-64.
- (`D102569 `_)
-
-Breaking changes
-----------------
-
-* ``--shuffle-sections=`` has been changed to ``--shuffle-sections==``.
- Specify ``*`` as ```` to get the previous behavior.
-
-COFF Improvements
------------------
-
-* Avoid thread exhaustion when running on 32 bit Windows.
- (`D105506 `_)
-
-* Improve terminating the process on Windows while a thread pool might be
- running. (`D102944 `_)
-
-MinGW Improvements
-------------------
-
-* Support for linking directly against a DLL without using an import library
- has been added. (`D104530 `_ and
- `D104531 `_)
-
-* Fix linking with ``--export-all-symbols`` in combination with
- ``-function-sections``. (`D101522 `_ and
- `D101615 `_)
-
-* Fix automatic export of symbols from LTO objects.
- (`D101569 `_)
-
-* Accept more spellings of some options.
- (`D107237 `_ and
- `D107253 `_)
-
-Mach-O Improvements
--------------------
-
-The Mach-O backend is now able to link several large, real-world programs,
-though we are still working out the kinks.
-
-* arm64 is now supported as a target. (`D88629 `_)
-* arm64_32 is now supported as a target. (`D99822 `_)
-* Branch-range-extension thunks are now supported. (`D100818 `_)
-* ``-dead_strip`` is now supported. (`D103324 `_)
-* Support for identical code folding (``--icf=all``) has been added.
- (`D103292 `_)
-* Support for special ``$start`` and ``$end`` symbols for segment & sections has been
- added. (`D106767 `_, `D106629 `_)
-* ``$ld$previous`` symbols are now supported. (`D103505 `_)
-* ``$ld$install_name`` symbols are now supported. (`D103746 `_)
-* ``__mh_*_header`` symbols are now supported. (`D97007 `_)
-* LC_CODE_SIGNATURE is now supported. (`D96164 `_)
-* LC_FUNCTION_STARTS is now supported. (`D97260 `_)
-* LC_DATA_IN_CODE is now supported. (`D103006 `_)
-* Bind opcodes are more compactly encoded. (`D106128 `_,
- `D105075 `_)
-* LTO cache support has been added. (`D105922 `_)
-* ``-application_extension`` is now supported. (`D105818 `_)
-* ``-export_dynamic`` is now partially supported. (`D105482 `_)
-* ``-arch_multiple`` is now supported. (`D105450 `_)
-* ``-final_output`` is now supported. (`D105449 `_)
-* ``-umbrella`` is now supported. (`D105448 `_)
-* ``--print-dylib-search`` is now supported. (`D103985 `_)
-* ``-force_load_swift_libs`` is now supported. (`D103709 `_)
-* ``-reexport_framework``, ``-reexport_library``, ``-reexport-l`` are now supported.
- (`D103497 `_)
-* ``.weak_def_can_be_hidden`` is now supported. (`D101080 `_)
-* ``-add_ast_path`` is now supported. (`D100076 `_)
-* ``-segprot`` is now supported. (`D99389 `_)
-* ``-dependency_info`` is now partially supported. (`D98559 `_)
-* ``--time-trace`` is now supported. (`D98419 `_)
-* ``-mark_dead_strippable_dylib`` is now supported. (`D98262 `_)
-* ``-[un]exported_symbol[s_list]`` is now supported. (`D98223 `_)
-* ``-flat_namespace`` is now supported. (`D97641 `_)
-* ``-rename_section`` and ``-rename_segment`` are now supported. (`D97600 `_)
-* ``-bundle_loader`` is now supported. (`D95913 `_)
-* ``-map`` is now partially supported. (`D98323 `_)
-
-There were numerous other bug-fixes as well.
-
-WebAssembly Improvements
-------------------------
-
diff --git a/lld/docs/WebAssembly.rst b/lld/docs/WebAssembly.rst
deleted file mode 100644
index c01df99cdd..0000000000
--- a/lld/docs/WebAssembly.rst
+++ /dev/null
@@ -1,210 +0,0 @@
-WebAssembly lld port
-====================
-
-The WebAssembly version of lld takes WebAssembly binaries as inputs and produces
-a WebAssembly binary as its output. For the most part it tries to mimic the
-behaviour of traditional ELF linkers and specifically the ELF lld port. Where
-possible the command line flags and the semantics should be the same.
-
-
-Object file format
-------------------
-
-The WebAssembly object file format used by LLVM and LLD is specified as part of
-the WebAssembly tool conventions on linking_.
-
-This is the object format that the llvm will produce when run with the
-``wasm32-unknown-unknown`` target.
-
-Usage
------
-
-The WebAssembly version of lld is installed as **wasm-ld**. It shared many
-common linker flags with **ld.lld** but also includes several
-WebAssembly-specific options:
-
-.. option:: --no-entry
-
- Don't search for the entry point symbol (by default ``_start``).
-
-.. option:: --export-table
-
- Export the function table to the environment.
-
-.. option:: --import-table
-
- Import the function table from the environment.
-
-.. option:: --export-all
-
- Export all symbols (normally combined with --no-gc-sections)
-
- Note that this will not export linker-generated mutable globals unless
- the resulting binaryen already includes the 'mutable-globals' features
- since that would otherwise create and invalid binaryen.
-
-.. option:: --export-dynamic
-
- When building an executable, export any non-hidden symbols. By default only
- the entry point and any symbols marked as exports (either via the command line
- or via the `export-name` source attribute) are exported.
-
-.. option:: --global-base=
-
- Address at which to place global data.
-
-.. option:: --no-merge-data-segments
-
- Disable merging of data segments.
-
-.. option:: --stack-first
-
- Place stack at start of linear memory rather than after data.
-
-.. option:: --compress-relocations
-
- Relocation targets in the code section are 5-bytes wide in order to
- potentially accommodate the largest LEB128 value. This option will cause the
- linker to shrink the code section to remove any padding from the final
- output. However because it affects code offset, this option is not
- compatible with outputting debug information.
-
-.. option:: --allow-undefined
-
- Allow undefined symbols in linked binary. This is the legacy
- flag which corresponds to ``--unresolve-symbols=ignore`` +
- ``--import-undefined``.
-
-.. option:: --unresolved-symbols=
-
- This is a more full featured version of ``--allow-undefined``.
- The semanatics of the different methods are as follows:
-
- report-all:
-
- Report all unresolved symbols. This is the default. Normally the linker
- will generate an error message for each reported unresolved symbol but the
- option ``--warn-unresolved-symbols`` can change this to a warning.
-
- ignore-all:
-
- Resolve all undefined symbols to zero. For data and function addresses
- this is trivial. For direct function calls, the linker will generate a
- trapping stub function in place of the undefined function.
-
-.. option:: --import-memory
-
- Import memory from the environment.
-
-.. option:: --import-undefined
-
- Generate WebAssembly imports for undefined symbols, where possible. For
- example, for function symbols this is always possible, but in general this
- is not possible for undefined data symbols. Undefined data symbols will
- still be reported as normal (in accordance with ``--unresolved-symbols``).
-
-.. option:: --initial-memory=
-
- Initial size of the linear memory. Default: static data size.
-
-.. option:: --max-memory=
-
- Maximum size of the linear memory. Default: unlimited.
-
-By default the function table is neither imported nor exported, but defined
-for internal use only.
-
-Behaviour
----------
-
-In general, where possible, the WebAssembly linker attempts to emulate the
-behaviour of a traditional ELF linker, and in particular the ELF port of lld.
-For more specific details on how this is achieved see the tool conventions on
-linking_.
-
-Function Signatures
-~~~~~~~~~~~~~~~~~~~
-
-One way in which the WebAssembly linker differs from traditional native linkers
-is that function signature checking is strict in WebAssembly. It is a
-validation error for a module to contain a call site that doesn't agree with
-the target signature. Even though this is undefined behaviour in C/C++, it is not
-uncommon to find this in real-world C/C++ programs. For example, a call site in
-one compilation unit which calls a function defined in another compilation
-unit but with too many arguments.
-
-In order not to generate such invalid modules, lld has two modes of handling such
-mismatches: it can simply error-out or it can create stub functions that will
-trap at runtime (functions that contain only an ``unreachable`` instruction)
-and use these stub functions at the otherwise invalid call sites.
-
-The default behaviour is to generate these stub function and to produce
-a warning. The ``--fatal-warnings`` flag can be used to disable this behaviour
-and error out if mismatched are found.
-
-Exports
-~~~~~~~
-
-When building a shared library any symbols marked as ``visibility=default`` will
-be exported.
-
-When building an executable, only the entry point (``_start``) and symbols with
-the ``WASM_SYMBOL_EXPORTED`` flag are exported by default. In LLVM the
-``WASM_SYMBOL_EXPORTED`` flag is set by the ``wasm-export-name`` attribute which
-in turn can be set using ``__attribute__((export_name))`` clang attribute.
-
-In addition, symbols can be exported via the linker command line using
-``--export`` (which will error if the symbol is not found) or
-``--export-if-defined`` (which will not).
-
-Finally, just like with native ELF linker the ``--export-dynamic`` flag can be
-used to export symbols in the executable which are marked as
-``visibility=default``.
-
-Imports
-~~~~~~~
-
-By default no undefined symbols are allowed in the final binary. The flag
-``--allow-undefined`` results in a WebAssembly import being defined for each
-undefined symbol. It is then up to the runtime to provide such symbols.
-
-Alternatively symbols can be marked in the source code as with the
-``import_name`` and/or ``import_module`` clang attributes which signals that
-they are expected to be undefined at static link time.
-
-Garbage Collection
-~~~~~~~~~~~~~~~~~~
-
-Since WebAssembly is designed with size in mind the linker defaults to
-``--gc-sections`` which means that all unused functions and data segments will
-be stripped from the binary.
-
-The symbols which are preserved by default are:
-
-- The entry point (by default ``_start``).
-- Any symbol which is to be exported.
-- Any symbol transitively referenced by the above.
-
-Weak Undefined Functions
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-On native platforms, calls to weak undefined functions end up as calls to the
-null function pointer. With WebAssembly, direct calls must reference a defined
-function (with the correct signature). In order to handle this case the linker
-will generate function a stub containing only the ``unreachable`` instruction
-and use this for any direct references to an undefined weak function.
-
-For example a runtime call to a weak undefined function ``foo`` will up trapping
-on ``unreachable`` inside and linker-generated function called
-``undefined:foo``.
-
-Missing features
-----------------
-
-- Merging of data section similar to ``SHF_MERGE`` in the ELF world is not
- supported.
-- No support for creating shared libraries. The spec for shared libraries in
- WebAssembly is still in flux:
- https://github.com/WebAssembly/tool-conventions/blob/master/DynamicLinking.md
-
-.. _linking: https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md
diff --git a/lld/docs/_static/favicon.ico b/lld/docs/_static/favicon.ico
deleted file mode 100644
index 724ad6e12d..0000000000
Binary files a/lld/docs/_static/favicon.ico and /dev/null differ
diff --git a/lld/docs/_templates/indexsidebar.html b/lld/docs/_templates/indexsidebar.html
deleted file mode 100644
index 588be9309b..0000000000
--- a/lld/docs/_templates/indexsidebar.html
+++ /dev/null
@@ -1,4 +0,0 @@
-
Bugs
-
-
lld bugs should be reported at the
- LLVM Bugzilla.
-{% endblock %}
diff --git a/lld/docs/conf.py b/lld/docs/conf.py
deleted file mode 100644
index 2df1aa7081..0000000000
--- a/lld/docs/conf.py
+++ /dev/null
@@ -1,255 +0,0 @@
-# -*- coding: utf-8 -*-
-#
-# lld documentation build configuration file.
-#
-# This file is execfile()d with the current directory set to its containing dir.
-#
-# Note that not all possible configuration values are present in this
-# autogenerated file.
-#
-# All configuration values have a default; values that are commented out
-# serve to show the default.
-
-import sys, os
-from datetime import date
-
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-#sys.path.insert(0, os.path.abspath('.'))
-
-# -- General configuration -----------------------------------------------------
-
-# If your documentation needs a minimal Sphinx version, state it here.
-#needs_sphinx = '1.0'
-
-# Add any Sphinx extension module names here, as strings. They can be extensions
-# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
-extensions = ['sphinx.ext.intersphinx', 'sphinx.ext.todo']
-
-# Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
-
-# The suffix of source filenames.
-source_suffix = '.rst'
-
-# The encoding of source files.
-#source_encoding = 'utf-8-sig'
-
-# The master toctree document.
-master_doc = 'index'
-
-# General information about the project.
-project = u'lld'
-copyright = u'2011-%d, LLVM Project' % date.today().year
-
-# The version info for the project you're documenting, acts as replacement for
-# |version| and |release|, also used in various other places throughout the
-# built documents.
-#
-# The short version.
-version = '13'
-# The full version, including alpha/beta/rc tags.
-release = '13'
-
-# The language for content autogenerated by Sphinx. Refer to documentation
-# for a list of supported languages.
-#language = None
-
-# There are two options for replacing |today|: either, you set today to some
-# non-false value, then it is used:
-#today = ''
-# Else, today_fmt is used as the format for a strftime call.
-today_fmt = '%Y-%m-%d'
-
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-exclude_patterns = ['_build']
-
-# The reST default role (used for this markup: `text`) to use for all documents.
-#default_role = None
-
-# If true, '()' will be appended to :func: etc. cross-reference text.
-#add_function_parentheses = True
-
-# If true, the current module name will be prepended to all description
-# unit titles (such as .. function::).
-#add_module_names = True
-
-# If true, sectionauthor and moduleauthor directives will be shown in the
-# output. They are ignored by default.
-show_authors = True
-
-# The name of the Pygments (syntax highlighting) style to use.
-pygments_style = 'friendly'
-
-# A list of ignored prefixes for module index sorting.
-#modindex_common_prefix = []
-
-
-# -- Options for HTML output ---------------------------------------------------
-
-# The theme to use for HTML and HTML Help pages. See the documentation for
-# a list of builtin themes.
-html_theme = 'llvm-theme'
-
-# Theme options are theme-specific and customize the look and feel of a theme
-# further. For a list of options available for each theme, see the
-# documentation.
-#html_theme_options = {}
-
-# Add any paths that contain custom themes here, relative to this directory.
-html_theme_path = ["."]
-
-# The name for this set of Sphinx documents. If None, it defaults to
-# " v documentation".
-#html_title = None
-
-# A shorter title for the navigation bar. Default is the same as html_title.
-#html_short_title = None
-
-# The name of an image file (relative to this directory) to place at the top
-# of the sidebar.
-#html_logo = None
-
-# If given, this must be the name of an image file (path relative to the
-# configuration directory) that is the favicon of the docs. Modern browsers use
-# this as icon for tabs, windows and bookmarks. It should be a Windows-style
-# icon file (.ico), which is 16x16 or 32x32 pixels large. Default: None. The
-# image file will be copied to the _static directory of the output HTML, but
-# only if the file does not already exist there.
-html_favicon = '_static/favicon.ico'
-
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['_static']
-
-# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
-# using the given strftime format.
-html_last_updated_fmt = '%Y-%m-%d'
-
-# If true, SmartyPants will be used to convert quotes and dashes to
-# typographically correct entities.
-#html_use_smartypants = True
-
-# Custom sidebar templates, maps document names to template names.
-html_sidebars = {'index': ['indexsidebar.html']}
-
-# Additional templates that should be rendered to pages, maps page names to
-# template names.
-# html_additional_pages = {'index': 'index.html'}
-
-# If false, no module index is generated.
-#html_domain_indices = True
-
-# If false, no index is generated.
-#html_use_index = True
-
-# If true, the index is split into individual pages for each letter.
-#html_split_index = False
-
-# If true, links to the reST sources are added to the pages.
-html_show_sourcelink = True
-
-# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
-#html_show_sphinx = True
-
-# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
-#html_show_copyright = True
-
-# If true, an OpenSearch description file will be output, and all pages will
-# contain a tag referring to it. The value of this option must be the
-# base URL from which the finished HTML is served.
-#html_use_opensearch = ''
-
-# This is the file name suffix for HTML files (e.g. ".xhtml").
-#html_file_suffix = None
-
-# Output file base name for HTML help builder.
-htmlhelp_basename = 'llddoc'
-
-
-# -- Options for LaTeX output --------------------------------------------------
-
-latex_elements = {
-# The paper size ('letterpaper' or 'a4paper').
-#'papersize': 'letterpaper',
-
-# The font size ('10pt', '11pt' or '12pt').
-#'pointsize': '10pt',
-
-# Additional stuff for the LaTeX preamble.
-#'preamble': '',
-}
-
-# Grouping the document tree into LaTeX files. List of tuples
-# (source start file, target name, title, author, documentclass [howto/manual]).
-latex_documents = [
- ('contents', 'lld.tex', u'lld Documentation',
- u'LLVM project', 'manual'),
-]
-
-# The name of an image file (relative to this directory) to place at the top of
-# the title page.
-#latex_logo = None
-
-# For "manual" documents, if this is true, then toplevel headings are parts,
-# not chapters.
-#latex_use_parts = False
-
-# If true, show page references after internal links.
-#latex_show_pagerefs = False
-
-# If true, show URL addresses after external links.
-#latex_show_urls = False
-
-# Documents to append as an appendix to all manuals.
-#latex_appendices = []
-
-# If false, no module index is generated.
-#latex_domain_indices = True
-
-
-# -- Options for manual page output --------------------------------------------
-
-# One entry per manual page. List of tuples
-# (source start file, name, description, authors, manual section).
-man_pages = [
- ('contents', 'lld', u'lld Documentation',
- [u'LLVM project'], 1)
-]
-
-# If true, show URL addresses after external links.
-#man_show_urls = False
-
-
-# -- Options for Texinfo output ------------------------------------------------
-
-# Grouping the document tree into Texinfo files. List of tuples
-# (source start file, target name, title, author,
-# dir menu entry, description, category)
-texinfo_documents = [
- ('contents', 'lld', u'lld Documentation',
- u'LLVM project', 'lld', 'One line description of project.',
- 'Miscellaneous'),
-]
-
-# Documents to append as an appendix to all manuals.
-#texinfo_appendices = []
-
-# If false, no module index is generated.
-#texinfo_domain_indices = True
-
-# How to display URL addresses: 'footnote', 'no', or 'inline'.
-#texinfo_show_urls = 'footnote'
-
-
-# FIXME: Define intersphinx configuration.
-intersphinx_mapping = {}
-
-
-# -- Options for extensions ----------------------------------------------------
-
-# Enable this if you want TODOs to show up in the generated documentation.
-todo_include_todos = True
diff --git a/lld/docs/design.rst b/lld/docs/design.rst
deleted file mode 100644
index 20d8fe78a6..0000000000
--- a/lld/docs/design.rst
+++ /dev/null
@@ -1,421 +0,0 @@
-.. _design:
-
-Linker Design
-=============
-
-Note: this document discuss Mach-O port of LLD. For ELF and COFF,
-see :doc:`index`.
-
-Introduction
-------------
-
-lld is a new generation of linker. It is not "section" based like traditional
-linkers which mostly just interlace sections from multiple object files into the
-output file. Instead, lld is based on "Atoms". Traditional section based
-linking work well for simple linking, but their model makes advanced linking
-features difficult to implement. Features like dead code stripping, reordering
-functions for locality, and C++ coalescing require the linker to work at a finer
-grain.
-
-An atom is an indivisible chunk of code or data. An atom has a set of
-attributes, such as: name, scope, content-type, alignment, etc. An atom also
-has a list of References. A Reference contains: a kind, an optional offset, an
-optional addend, and an optional target atom.
-
-The Atom model allows the linker to use standard graph theory models for linking
-data structures. Each atom is a node, and each Reference is an edge. The
-feature of dead code stripping is implemented by following edges to mark all
-live atoms, and then delete the non-live atoms.
-
-
-Atom Model
-----------
-
-An atom is an indivisible chunk of code or data. Typically each user written
-function or global variable is an atom. In addition, the compiler may emit
-other atoms, such as for literal c-strings or floating point constants, or for
-runtime data structures like dwarf unwind info or pointers to initializers.
-
-A simple "hello world" object file would be modeled like this:
-
-.. image:: hello.png
-
-There are three atoms: main, a proxy for printf, and an anonymous atom
-containing the c-string literal "hello world". The Atom "main" has two
-references. One is the call site for the call to printf, and the other is a
-reference for the instruction that loads the address of the c-string literal.
-
-There are only four different types of atoms:
-
- * DefinedAtom
- 95% of all atoms. This is a chunk of code or data
-
- * UndefinedAtom
- This is a place holder in object files for a reference to some atom
- outside the translation unit.During core linking it is usually replaced
- by (coalesced into) another Atom.
-
- * SharedLibraryAtom
- If a required symbol name turns out to be defined in a dynamic shared
- library (and not some object file). A SharedLibraryAtom is the
- placeholder Atom used to represent that fact.
-
- It is similar to an UndefinedAtom, but it also tracks information
- about the associated shared library.
-
- * AbsoluteAtom
- This is for embedded support where some stuff is implemented in ROM at
- some fixed address. This atom has no content. It is just an address
- that the Writer needs to fix up any references to point to.
-
-
-File Model
-----------
-
-The linker views the input files as basically containers of Atoms and
-References, and just a few attributes of their own. The linker works with three
-kinds of files: object files, static libraries, and dynamic shared libraries.
-Each kind of file has reader object which presents the file in the model
-expected by the linker.
-
-Object File
-~~~~~~~~~~~
-
-An object file is just a container of atoms. When linking an object file, a
-reader is instantiated which parses the object file and instantiates a set of
-atoms representing all content in the .o file. The linker adds all those atoms
-to a master graph.
-
-Static Library (Archive)
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-This is the traditional unix static archive which is just a collection of object
-files with a "table of contents". When linking with a static library, by default
-nothing is added to the master graph of atoms. Instead, if after merging all
-atoms from object files into a master graph, if any "undefined" atoms are left
-remaining in the master graph, the linker reads the table of contents for each
-static library to see if any have the needed definitions. If so, the set of
-atoms from the specified object file in the static library is added to the
-master graph of atoms.
-
-Dynamic Library (Shared Object)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Dynamic libraries are different than object files and static libraries in that
-they don't directly add any content. Their purpose is to check at build time
-that the remaining undefined references can be resolved at runtime, and provide
-a list of dynamic libraries (SO_NEEDED) that will be needed at runtime. The way
-this is modeled in the linker is that a dynamic library contributes no atoms to
-the initial graph of atoms. Instead, (like static libraries) if there are
-"undefined" atoms in the master graph of all atoms, then each dynamic library is
-checked to see if exports the required symbol. If so, a "shared library" atom is
-instantiated by the by the reader which the linker uses to replace the
-"undefined" atom.
-
-Linking Steps
--------------
-
-Through the use of abstract Atoms, the core of linking is architecture
-independent and file format independent. All command line parsing is factored
-out into a separate "options" abstraction which enables the linker to be driven
-with different command line sets.
-
-The overall steps in linking are:
-
- #. Command line processing
-
- #. Parsing input files
-
- #. Resolving
-
- #. Passes/Optimizations
-
- #. Generate output file
-
-The Resolving and Passes steps are done purely on the master graph of atoms, so
-they have no notion of file formats such as mach-o or ELF.
-
-
-Input Files
-~~~~~~~~~~~
-
-Existing developer tools using different file formats for object files.
-A goal of lld is to be file format independent. This is done
-through a plug-in model for reading object files. The lld::Reader is the base
-class for all object file readers. A Reader follows the factory method pattern.
-A Reader instantiates an lld::File object (which is a graph of Atoms) from a
-given object file (on disk or in-memory).
-
-Every Reader subclass defines its own "options" class (for instance the mach-o
-Reader defines the class ReaderOptionsMachO). This options class is the
-one-and-only way to control how the Reader operates when parsing an input file
-into an Atom graph. For instance, you may want the Reader to only accept
-certain architectures. The options class can be instantiated from command
-line options, or it can be subclassed and the ivars programmatically set.
-
-Resolving
-~~~~~~~~~
-
-The resolving step takes all the atoms' graphs from each object file and
-combines them into one master object graph. Unfortunately, it is not as simple
-as appending the atom list from each file into one big list. There are many
-cases where atoms need to be coalesced. That is, two or more atoms need to be
-coalesced into one atom. This is necessary to support: C language "tentative
-definitions", C++ weak symbols for templates and inlines defined in headers,
-replacing undefined atoms with actual definition atoms, and for merging copies
-of constants like c-strings and floating point constants.
-
-The linker support coalescing by-name and by-content. By-name is used for
-tentative definitions and weak symbols. By-content is used for constant data
-that can be merged.
-
-The resolving process maintains some global linking "state", including a "symbol
-table" which is a map from llvm::StringRef to lld::Atom*. With these data
-structures, the linker iterates all atoms in all input files. For each atom, it
-checks if the atom is named and has a global or hidden scope. If so, the atom
-is added to the symbol table map. If there already is a matching atom in that
-table, that means the current atom needs to be coalesced with the found atom, or
-it is a multiple definition error.
-
-When all initial input file atoms have been processed by the resolver, a scan is
-made to see if there are any undefined atoms in the graph. If there are, the
-linker scans all libraries (both static and dynamic) looking for definitions to
-replace the undefined atoms. It is an error if any undefined atoms are left
-remaining.
-
-Dead code stripping (if requested) is done at the end of resolving. The linker
-does a simple mark-and-sweep. It starts with "root" atoms (like "main" in a main
-executable) and follows each references and marks each Atom that it visits as
-"live". When done, all atoms not marked "live" are removed.
-
-The result of the Resolving phase is the creation of an lld::File object. The
-goal is that the lld::File model is **the** internal representation
-throughout the linker. The file readers parse (mach-o, ELF, COFF) into an
-lld::File. The file writers (mach-o, ELF, COFF) taken an lld::File and produce
-their file kind, and every Pass only operates on an lld::File. This is not only
-a simpler, consistent model, but it enables the state of the linker to be dumped
-at any point in the link for testing purposes.
-
-
-Passes
-~~~~~~
-
-The Passes step is an open ended set of routines that each get a change to
-modify or enhance the current lld::File object. Some example Passes are:
-
- * stub (PLT) generation
-
- * GOT instantiation
-
- * order_file optimization
-
- * branch island generation
-
- * branch shim generation
-
- * Objective-C optimizations (Darwin specific)
-
- * TLV instantiation (Darwin specific)
-
- * DTrace probe processing (Darwin specific)
-
- * compact unwind encoding (Darwin specific)
-
-
-Some of these passes are specific to Darwin's runtime environments. But many of
-the passes are applicable to any OS (such as generating branch island for out of
-range branch instructions).
-
-The general structure of a pass is to iterate through the atoms in the current
-lld::File object, inspecting each atom and doing something. For instance, the
-stub pass, looks for call sites to shared library atoms (e.g. call to printf).
-It then instantiates a "stub" atom (PLT entry) and a "lazy pointer" atom for
-each proxy atom needed, and these new atoms are added to the current lld::File
-object. Next, all the noted call sites to shared library atoms have their
-References altered to point to the stub atom instead of the shared library atom.
-
-
-Generate Output File
-~~~~~~~~~~~~~~~~~~~~
-
-Once the passes are done, the output file writer is given current lld::File
-object. The writer's job is to create the executable content file wrapper and
-place the content of the atoms into it.
-
-lld uses a plug-in model for writing output files. All concrete writers (e.g.
-ELF, mach-o, etc) are subclasses of the lld::Writer class.
-
-Unlike the Reader class which has just one method to instantiate an lld::File,
-the Writer class has multiple methods. The crucial method is to generate the
-output file, but there are also methods which allow the Writer to contribute
-Atoms to the resolver and specify passes to run.
-
-An example of contributing
-atoms is that if the Writer knows a main executable is being linked and such
-an executable requires a specially named entry point (e.g. "_main"), the Writer
-can add an UndefinedAtom with that special name to the resolver. This will
-cause the resolver to issue an error if that symbol is not defined.
-
-Sometimes a Writer supports lazily created symbols, such as names for the start
-of sections. To support this, the Writer can create a File object which vends
-no initial atoms, but does lazily supply atoms by name as needed.
-
-Every Writer subclass defines its own "options" class (for instance the mach-o
-Writer defines the class WriterOptionsMachO). This options class is the
-one-and-only way to control how the Writer operates when producing an output
-file from an Atom graph. For instance, you may want the Writer to optimize
-the output for certain OS versions, or strip local symbols, etc. The options
-class can be instantiated from command line options, or it can be subclassed
-and the ivars programmatically set.
-
-
-lld::File representations
--------------------------
-
-Just as LLVM has three representations of its IR model, lld has two
-representations of its File/Atom/Reference model:
-
- * In memory, abstract C++ classes (lld::Atom, lld::Reference, and lld::File).
-
- * textual (in YAML)
-
-
-Textual representations in YAML
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-In designing a textual format we want something easy for humans to read and easy
-for the linker to parse. Since an atom has lots of attributes most of which are
-usually just the default, we should define default values for every attribute so
-that those can be omitted from the text representation. Here is the atoms for a
-simple hello world program expressed in YAML::
-
- target-triple: x86_64-apple-darwin11
-
- atoms:
- - name: _main
- scope: global
- type: code
- content: [ 55, 48, 89, e5, 48, 8d, 3d, 00, 00, 00, 00, 30, c0, e8, 00, 00,
- 00, 00, 31, c0, 5d, c3 ]
- fixups:
- - offset: 07
- kind: pcrel32
- target: 2
- - offset: 0E
- kind: call32
- target: _fprintf
-
- - type: c-string
- content: [ 73, 5A, 00 ]
-
- ...
-
-The biggest use for the textual format will be writing test cases. Writing test
-cases in C is problematic because the compiler may vary its output over time for
-its own optimization reasons which my inadvertently disable or break the linker
-feature trying to be tested. By writing test cases in the linkers own textual
-format, we can exactly specify every attribute of every atom and thus target
-specific linker logic.
-
-The textual/YAML format follows the ReaderWriter patterns used in lld. The lld
-library comes with the classes: ReaderYAML and WriterYAML.
-
-
-Testing
--------
-
-The lld project contains a test suite which is being built up as new code is
-added to lld. All new lld functionality should have a tests added to the test
-suite. The test suite is `lit `_ driven. Each
-test is a text file with comments telling lit how to run the test and check the
-result To facilitate testing, the lld project builds a tool called lld-core.
-This tool reads a YAML file (default from stdin), parses it into one or more
-lld::File objects in memory and then feeds those lld::File objects to the
-resolver phase.
-
-
-Resolver testing
-~~~~~~~~~~~~~~~~
-
-Basic testing is the "core linking" or resolving phase. That is where the
-linker merges object files. All test cases are written in YAML. One feature of
-YAML is that it allows multiple "documents" to be encoding in one YAML stream.
-That means one text file can appear to the linker as multiple .o files - the
-normal case for the linker.
-
-Here is a simple example of a core linking test case. It checks that an
-undefined atom from one file will be replaced by a definition from another
-file::
-
- # RUN: lld-core %s | FileCheck %s
-
- #
- # Test that undefined atoms are replaced with defined atoms.
- #
-
- ---
- atoms:
- - name: foo
- definition: undefined
- ---
- atoms:
- - name: foo
- scope: global
- type: code
- ...
-
- # CHECK: name: foo
- # CHECK: scope: global
- # CHECK: type: code
- # CHECK-NOT: name: foo
- # CHECK: ...
-
-
-Passes testing
-~~~~~~~~~~~~~~
-
-Since Passes just operate on an lld::File object, the lld-core tool has the
-option to run a particular pass (after resolving). Thus, you can write a YAML
-test case with carefully crafted input to exercise areas of a Pass and the check
-the resulting lld::File object as represented in YAML.
-
-
-Design Issues
--------------
-
-There are a number of open issues in the design of lld. The plan is to wait and
-make these design decisions when we need to.
-
-
-Debug Info
-~~~~~~~~~~
-
-Currently, the lld model says nothing about debug info. But the most popular
-debug format is DWARF and there is some impedance mismatch with the lld model
-and DWARF. In lld there are just Atoms and only Atoms that need to be in a
-special section at runtime have an associated section. Also, Atoms do not have
-addresses. The way DWARF is spec'ed different parts of DWARF are supposed to go
-into specially named sections and the DWARF references function code by address.
-
-CPU and OS specific functionality
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Currently, lld has an abstract "Platform" that deals with any CPU or OS specific
-differences in linking. We just keep adding virtual methods to the base
-Platform class as we find linking areas that might need customization. At some
-point we'll need to structure this better.
-
-
-File Attributes
-~~~~~~~~~~~~~~~
-
-Currently, lld::File just has a path and a way to iterate its atoms. We will
-need to add more attributes on a File. For example, some equivalent to the
-target triple. There is also a number of cached or computed attributes that
-could make various Passes more efficient. For instance, on Darwin there are a
-number of Objective-C optimizations that can be done by a Pass. But it would
-improve the plain C case if the Objective-C optimization Pass did not have to
-scan all atoms looking for any Objective-C data structures. This could be done
-if the lld::File object had an attribute that said if the file had any
-Objective-C data in it. The Resolving phase would then be required to "merge"
-that attribute as object files are added.
diff --git a/lld/docs/development.rst b/lld/docs/development.rst
deleted file mode 100644
index 81b826f648..0000000000
--- a/lld/docs/development.rst
+++ /dev/null
@@ -1,45 +0,0 @@
-.. _development:
-
-Development
-===========
-
-Note: this document discuss Mach-O port of LLD. For ELF and COFF,
-see :doc:`index`.
-
-lld is developed as part of the `LLVM `_ project.
-
-Creating a Reader
------------------
-
-See the :ref:`Creating a Reader ` guide.
-
-
-Modifying the Driver
---------------------
-
-See :doc:`Driver`.
-
-
-Debugging
----------
-
-You can run lld with ``-mllvm -debug`` command line options to enable debugging
-printouts. If you want to enable debug information for some specific pass, you
-can run it with ``-mllvm '-debug-only='``, where pass is a name used in
-the ``DEBUG_WITH_TYPE()`` macro.
-
-
-
-Documentation
--------------
-
-The project documentation is written in reStructuredText and generated using the
-`Sphinx `_ documentation generator. For more
-information on writing documentation for the project, see the
-:ref:`sphinx_intro`.
-
-.. toctree::
- :hidden:
-
- Readers
- Driver
diff --git a/lld/docs/error_handling_script.rst b/lld/docs/error_handling_script.rst
deleted file mode 100644
index 53efa8b7a3..0000000000
--- a/lld/docs/error_handling_script.rst
+++ /dev/null
@@ -1,39 +0,0 @@
-=====================
-Error Handling Script
-=====================
-
-LLD provides the ability to hook into some error handling routines through a
-user-provided script specified with ``--error-handling-script=``
-when certain errors are encountered. This document specifies the requirements of
-such a script.
-
-Generic Requirements
-====================
-
-The script is expected to be available in the ``PATH`` or to be provided using a
-full path. It must be executable. It is executed in the same environment as the
-parent process.
-
-Arguments
-=========
-
-LLD calls the error handling script using the following arguments::
-
- error-handling-script
-
-The following tags are supported:
-
-- ``missing-lib``: indicates that LLD failed to find a library. The library name
- is specified as the second argument, e.g. ``error-handling-script missing-lib
- mylib``
-
-- ``undefined-symbol``: indicates that given symbol is marked as undefined. The
- unmangled symbol name is specified as the second argument, e.g.
- ``error-handling-script undefined-symbol mysymbol``
-
-Return Value
-============
-
-Upon success, the script is expected to return 0. A non-zero value is
-interpreted as an error and reported to the user. In both cases, LLD still
-reports the original error.
diff --git a/lld/docs/getting_started.rst b/lld/docs/getting_started.rst
deleted file mode 100644
index 506cb24dde..0000000000
--- a/lld/docs/getting_started.rst
+++ /dev/null
@@ -1,87 +0,0 @@
-.. _getting_started:
-
-Getting Started: Building and Running lld
-=========================================
-
-This page gives you the shortest path to checking out and building lld. If you
-run into problems, please file bugs in the `LLVM Bugzilla`__
-
-__ https://bugs.llvm.org/
-
-Building lld
-------------
-
-On Unix-like Systems
-~~~~~~~~~~~~~~~~~~~~
-
-1. Get the required tools.
-
- * `CMake 2.8`_\+.
- * make (or any build system CMake supports).
- * `Clang 3.1`_\+ or GCC 4.7+ (C++11 support is required).
-
- * If using Clang, you will also need `libc++`_.
- * `Python 2.4`_\+ (not 3.x) for running tests.
-
-.. _CMake 2.8: http://www.cmake.org/cmake/resources/software.html
-.. _Clang 3.1: http://clang.llvm.org/
-.. _libc++: http://libcxx.llvm.org/
-.. _Python 2.4: http://python.org/download/
-
-2. Check out LLVM and subprojects (including lld)::
-
- $ git clone https://github.com/llvm/llvm-project.git
-
-4. Build LLVM and lld::
-
- $ cd llvm-project
- $ mkdir build && cd build
- $ cmake -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS=lld ../llvm
- $ make
-
- * If you want to build with clang and it is not the default compiler or
- it is installed in an alternate location, you'll need to tell the cmake tool
- the location of the C and C++ compiler via CMAKE_C_COMPILER and
- CMAKE_CXX_COMPILER. For example::
-
- $ cmake -DCMAKE_CXX_COMPILER=/path/to/clang++ -DCMAKE_C_COMPILER=/path/to/clang ...
-
-5. Test::
-
- $ make check-lld
-
-Using Visual Studio
-~~~~~~~~~~~~~~~~~~~
-
-#. Get the required tools.
-
- * `CMake 2.8`_\+.
- * `Visual Studio 12 (2013) or later`_ (required for C++11 support)
- * `Python 2.4`_\+ (not 3.x) for running tests.
-
-.. _CMake 2.8: http://www.cmake.org/cmake/resources/software.html
-.. _Visual Studio 12 (2013) or later: http://www.microsoft.com/visualstudio/11/en-us
-.. _Python 2.4: http://python.org/download/
-
-#. Check out LLVM as above.
-
-#. Generate Visual Studio project files::
-
- $ cd llvm-project/build (out of source build required)
- $ cmake -G "Visual Studio 11" -DLLVM_ENABLE_PROJECTS=lld ../llvm
-
-#. Build
-
- * Open LLVM.sln in Visual Studio.
- * Build the ``ALL_BUILD`` target.
-
-#. Test
-
- * Build the ``lld-test`` target.
-
-More Information
-~~~~~~~~~~~~~~~~
-
-For more information on using CMake see the `LLVM CMake guide`_.
-
-.. _LLVM CMake guide: https://llvm.org/docs/CMake.html
diff --git a/lld/docs/hello.png b/lld/docs/hello.png
deleted file mode 100644
index 70df111f1a..0000000000
Binary files a/lld/docs/hello.png and /dev/null differ
diff --git a/lld/docs/index.rst b/lld/docs/index.rst
deleted file mode 100644
index b0080f54df..0000000000
--- a/lld/docs/index.rst
+++ /dev/null
@@ -1,182 +0,0 @@
-LLD - The LLVM Linker
-=====================
-
-LLD is a linker from the LLVM project that is a drop-in replacement
-for system linkers and runs much faster than them. It also provides
-features that are useful for toolchain developers.
-
-The linker supports ELF (Unix), PE/COFF (Windows), Mach-O (macOS) and
-WebAssembly in descending order of completeness. Internally, LLD consists of
-several different linkers. The ELF port is the one that will be described in
-this document. The PE/COFF port is complete, including
-Windows debug info (PDB) support. The WebAssembly port is still a work in
-progress (See :doc:`WebAssembly`). The Mach-O port is built based on a
-different architecture than the others. For the details about Mach-O, please
-read :doc:`AtomLLD`.
-
-Features
---------
-
-- LLD is a drop-in replacement for the GNU linkers that accepts the
- same command line arguments and linker scripts as GNU.
-
- We are currently working closely with the FreeBSD project to make
- LLD default system linker in future versions of the operating
- system, so we are serious about addressing compatibility issues. As
- of February 2017, LLD is able to link the entire FreeBSD/amd64 base
- system including the kernel. With a few work-in-progress patches it
- can link approximately 95% of the ports collection on AMD64. For the
- details, see `FreeBSD quarterly status report
- `_.
-
-- LLD is very fast. When you link a large program on a multicore
- machine, you can expect that LLD runs more than twice as fast as the GNU
- gold linker. Your mileage may vary, though.
-
-- It supports various CPUs/ABIs including AArch64, AMDGPU, ARM, Hexagon, MIPS
- 32/64 big/little-endian, PowerPC, PowerPC64, RISC-V, SPARC V9, x86-32 and
- x86-64. Among these, AArch64, ARM (>= v6), PowerPC, PowerPC64, x86-32 and
- x86-64 have production quality. MIPS seems decent too.
-
-- It is always a cross-linker, meaning that it always supports all the
- above targets however it was built. In fact, we don't provide a
- build-time option to enable/disable each target. This should make it
- easy to use our linker as part of a cross-compile toolchain.
-
-- You can embed LLD in your program to eliminate dependencies on
- external linkers. All you have to do is to construct object files
- and command line arguments just like you would do to invoke an
- external linker and then call the linker's main function,
- ``lld::elf::link``, from your code.
-
-- It is small. We are using LLVM libObject library to read from object
- files, so it is not a completely fair comparison, but as of February
- 2017, LLD/ELF consists only of 21k lines of C++ code while GNU gold
- consists of 198k lines of C++ code.
-
-- Link-time optimization (LTO) is supported by default. Essentially,
- all you have to do to do LTO is to pass the ``-flto`` option to clang.
- Then clang creates object files not in the native object file format
- but in LLVM bitcode format. LLD reads bitcode object files, compile
- them using LLVM and emit an output file. Because in this way LLD can
- see the entire program, it can do the whole program optimization.
-
-- Some very old features for ancient Unix systems (pre-90s or even
- before that) have been removed. Some default settings have been
- tuned for the 21st century. For example, the stack is marked as
- non-executable by default to tighten security.
-
-Performance
------------
-
-This is a link time comparison on a 2-socket 20-core 40-thread Xeon
-E5-2680 2.80 GHz machine with an SSD drive. We ran gold and lld with
-or without multi-threading support. To disable multi-threading, we
-added ``-no-threads`` to the command lines.
-
-============ =========== ============ ==================== ================== =============== =============
-Program Output size GNU ld GNU gold w/o threads GNU gold w/threads lld w/o threads lld w/threads
-ffmpeg dbg 92 MiB 1.72s 1.16s 1.01s 0.60s 0.35s
-mysqld dbg 154 MiB 8.50s 2.96s 2.68s 1.06s 0.68s
-clang dbg 1.67 GiB 104.03s 34.18s 23.49s 14.82s 5.28s
-chromium dbg 1.14 GiB 209.05s [1]_ 64.70s 60.82s 27.60s 16.70s
-============ =========== ============ ==================== ================== =============== =============
-
-As you can see, lld is significantly faster than GNU linkers.
-Note that this is just a benchmark result of our environment.
-Depending on number of available cores, available amount of memory or
-disk latency/throughput, your results may vary.
-
-.. [1] Since GNU ld doesn't support the ``-icf=all`` and
- ``-gdb-index`` options, we removed them from the command line
- for GNU ld. GNU ld would have been slower than this if it had
- these options.
-
-Build
------
-
-If you have already checked out LLVM using SVN, you can check out LLD
-under ``tools`` directory just like you probably did for clang. For the
-details, see `Getting Started with the LLVM System
-`_.
-
-If you haven't checked out LLVM, the easiest way to build LLD is to
-check out the entire LLVM projects/sub-projects from a git mirror and
-build that tree. You need `cmake` and of course a C++ compiler.
-
-.. code-block:: console
-
- $ git clone https://github.com/llvm/llvm-project llvm-project
- $ mkdir build
- $ cd build
- $ cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=lld -DCMAKE_INSTALL_PREFIX=/usr/local ../llvm-project/llvm
- $ make install
-
-Using LLD
----------
-
-LLD is installed as ``ld.lld``. On Unix, linkers are invoked by
-compiler drivers, so you are not expected to use that command
-directly. There are a few ways to tell compiler drivers to use ld.lld
-instead of the default linker.
-
-The easiest way to do that is to overwrite the default linker. After
-installing LLD to somewhere on your disk, you can create a symbolic
-link by doing ``ln -s /path/to/ld.lld /usr/bin/ld`` so that
-``/usr/bin/ld`` is resolved to LLD.
-
-If you don't want to change the system setting, you can use clang's
-``-fuse-ld`` option. In this way, you want to set ``-fuse-ld=lld`` to
-LDFLAGS when building your programs.
-
-LLD leaves its name and version number to a ``.comment`` section in an
-output. If you are in doubt whether you are successfully using LLD or
-not, run ``readelf --string-dump .comment `` and examine the
-output. If the string "Linker: LLD" is included in the output, you are
-using LLD.
-
-History
--------
-
-Here is a brief project history of the ELF and COFF ports.
-
-- May 2015: We decided to rewrite the COFF linker and did that.
- Noticed that the new linker is much faster than the MSVC linker.
-
-- July 2015: The new ELF port was developed based on the COFF linker
- architecture.
-
-- September 2015: The first patches to support MIPS and AArch64 landed.
-
-- October 2015: Succeeded to self-host the ELF port. We have noticed
- that the linker was faster than the GNU linkers, but we weren't sure
- at the time if we would be able to keep the gap as we would add more
- features to the linker.
-
-- July 2016: Started working on improving the linker script support.
-
-- December 2016: Succeeded to build the entire FreeBSD base system
- including the kernel. We had widen the performance gap against the
- GNU linkers.
-
-Internals
----------
-
-For the internals of the linker, please read :doc:`NewLLD`. It is a bit
-outdated but the fundamental concepts remain valid. We'll update the
-document soon.
-
-.. toctree::
- :maxdepth: 1
-
- NewLLD
- AtomLLD
- WebAssembly
- windows_support
- missingkeyfunction
- error_handling_script
- Partitions
- ReleaseNotes
- ELF/linker_script
- ELF/start-stop-gc
- ELF/warn_backrefs
diff --git a/lld/docs/ld.lld.1 b/lld/docs/ld.lld.1
deleted file mode 100644
index bd67e58daa..0000000000
--- a/lld/docs/ld.lld.1
+++ /dev/null
@@ -1,881 +0,0 @@
-.\" 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
-.\"
-.\" This man page documents only lld's ELF linking support, obtained originally
-.\" from FreeBSD.
-.Dd May 12, 2019
-.Dt LD.LLD 1
-.Os
-.Sh NAME
-.Nm ld.lld
-.Nd ELF linker from the LLVM project
-.Sh SYNOPSIS
-.Nm ld.lld
-.Op Ar options
-.Ar objfile ...
-.Sh DESCRIPTION
-A linker takes one or more object, archive, and library files, and combines
-them into an output file (an executable, a shared library, or another object
-file).
-It relocates code and data from the input files and resolves symbol
-references between them.
-.Pp
-.Nm
-is a drop-in replacement for the GNU BFD and gold linkers.
-It accepts most of the same command line arguments and linker scripts
-as GNU linkers.
-.Pp
-.Nm
-currently supports i386, x86-64, ARM, AArch64, PowerPC32, PowerPC64,
-MIPS32, MIPS64, RISC-V, AMDGPU, Hexagon and SPARC V9 targets.
-.Nm
-acts as a Microsoft link.exe-compatible linker if invoked as
-.Nm lld-link
-and as macOS's ld if invoked as
-.Nm ld.ld64.
-All these targets are always supported however
-.Nm
-was built, so you can always use
-.Nm
-as a native linker as well as a cross linker.
-.Sh OPTIONS
-Many options have both a single-letter and long form.
-When using the long form options other than those beginning with the
-letter
-.Cm o
-may be specified using either one or two dashes preceding the option name.
-Long options beginning with
-.Cm o
-require two dashes to avoid confusion with the
-.Fl o Ar path
-option.
-.Pp
-.Bl -tag -width indent
-.It Fl -allow-multiple-definition
-Do not error if a symbol is defined multiple times.
-The first definition will be used.
-.It Fl -allow-shlib-undefined
-Allow unresolved references in shared libraries.
-This option is enabled by default when linking a shared library.
-.It Fl -apply-dynamic-relocs
-Apply link-time values for dynamic relocations.
-.It Fl -as-needed
-Only set
-.Dv DT_NEEDED
-for shared libraries if used.
-.It Fl -auxiliary Ns = Ns Ar value
-Set the
-.Dv DT_AUXILIARY
-field to the specified name.
-.It Fl -Bdynamic , Fl -dy
-Link against shared libraries.
-.It Fl -Bstatic , Fl -static , Fl -dn
-Do not link against shared libraries.
-.It Fl Bno-symbolic
-Don't bind default visibility defined symbols locally for
-.Fl shared
-(default).
-.It Fl Bsymbolic
-Bind default visibility defined symbols locally for
-.Fl shared.
-Also set the
-.Dv DF_SYMBOLIC
-flag.
-.It Fl Bsymbolic-functions
-Bind default visibility defined function symbols locally for
-.Fl shared.
-.It Fl Bsymbolic-non-weak-functions
-Bind default visibility defined STB_GLOBAL function symbols locally for
-.Fl shared.
-.It Fl -build-id Ns = Ns Ar value
-Generate a build ID note.
-.Ar value
-may be one of
-.Cm fast ,
-.Cm md5 ,
-.Cm sha1 ,
-.Cm tree ,
-.Cm uuid ,
-.Cm 0x Ns Ar hex-string ,
-and
-.Cm none .
-.Cm tree
-is an alias for
-.Cm sha1 .
-Build-IDs of type
-.Cm fast ,
-.Cm md5 ,
-.Cm sha1 ,
-and
-.Cm tree
-are calculated from the object contents.
-.Cm fast
-is not intended to be cryptographically secure.
-.It Fl -build-id
-Synonym for
-.Fl -build-id Ns = Ns Cm fast .
-.It Fl -color-diagnostics Ns = Ns Ar value
-Use colors in diagnostics.
-.Ar value
-may be one of
-.Cm always ,
-.Cm auto ,
-and
-.Cm never .
-.Cm auto
-enables color if and only if output is to a terminal.
-.It Fl -color-diagnostics
-Alias for
-.Fl -color-diagnostics Ns = Ns Cm auto .
-.It Fl -compress-debug-sections Ns = Ns Ar value
-Compress DWARF debug sections.
-.Ar value
-may be
-.Cm none
-or
-.Cm zlib .
-The default compression level is 1 (fastest) as the debug info usually
-compresses well at that level, but if you want to compress it more,
-you can specify
-.Fl O2
-to set the compression level to 6.
-.It Fl -cref
-Output cross reference table.
-.It Fl -define-common , Fl d
-Assign space to common symbols.
-.It Fl -defsym Ns = Ns Ar symbol Ns = Ns Ar expression
-Define a symbol alias.
-.Ar expression
-may be another symbol or a linker script expression.
-For example,
-.Ql --defsym=foo=bar
-or
-.Ql --defsym=foo=bar+0x100 .
-.It Fl -demangle
-Demangle symbol names.
-.It Fl -disable-new-dtags
-Disable new dynamic tags.
-.It Fl -discard-all , Fl x
-Delete all local symbols.
-.It Fl -discard-locals , Fl X
-Delete temporary local symbols.
-.It Fl -discard-none
-Keep all symbols in the symbol table.
-.It Fl -dynamic-linker Ns = Ns Ar value
-Specify the dynamic linker to be used for a dynamically linked executable.
-This is recorded in an ELF segment of type
-.Dv PT_INTERP .
-.It Fl -dynamic-list Ns = Ns Ar file
-Read a list of dynamic symbols from
-.Ar file .
-(executable) Put matched non-local defined symbols to the dynamic symbol table.
-(shared object) References to matched non-local STV_DEFAULT symbols shouldn't be bound to definitions within the shared object. Implies
-.Cm -Bsymbolic
-but does not set DF_SYMBOLIC
-.It Fl -EB
-Select the big-endian format in the OUTPUT_FORMAT command.
-.It Fl -EL
-Select the little-endian format in the OUTPUT_FORMAT command.
-.It Fl -eh-frame-hdr
-Request creation of
-.Li .eh_frame_hdr
-section and
-.Dv PT_GNU_EH_FRAME
-segment header.
-.It Fl -emit-relocs , Fl q
-Generate relocations in the output.
-.It Fl -enable-new-dtags
-Enable new dynamic tags.
-.It Fl -end-lib
-End a grouping of objects that should be treated as if they were together
-in an archive.
-.It Fl -entry Ns = Ns Ar entry
-Name of entry point symbol.
-.It Fl -error-limit Ns = Ns Ar value
-Maximum number of errors to emit before stopping.
-A value of zero indicates that there is no limit.
-.It Fl -error-unresolved-symbols
-Report unresolved symbols as errors.
-.It Fl -error-handing-script Ns = Ns Ar script_path
-Call script
-.Ar script_path
-upon some error, with
-.Ar tag
-as first argument, and an extra parameter as second argument. The script is
-expected to return 0 on success. Any other value is considered a generic error.
-.Ar tag
-may be
-.Cm missing-lib
-followed by the name of the missing library.
-.Cm undefined-symbol
-followed by the name of the undefined symbol.
-.It Fl -execute-only
-Mark executable sections unreadable.
-This option is currently only supported on AArch64.
-.It Fl -exclude-libs Ns = Ns Ar value
-Exclude static libraries from automatic export.
-.It Fl -export-dynamic , Fl E
-Put symbols in the dynamic symbol table.
-.It Fl -export-dynamic-symbol Ns = Ns Ar glob
-(executable) Put matched non-local defined symbols to the dynamic symbol table.
-(shared object) References to matched non-local STV_DEFAULT symbols shouldn't be bound to definitions within the shared object even if they would otherwise be due to
-.Cm -Bsymbolic
-,
-.Cm -Bsymbolic-functions
-or
-.Cm --dynamic-list
-.It Fl -fatal-warnings
-Treat warnings as errors.
-.It Fl -filter Ns = Ns Ar value , Fl F Ar value
-Set the
-.Dv DT_FILTER
-field to the specified value.
-.It Fl -fini Ns = Ns Ar symbol
-Specify a finalizer function.
-.It Fl -format Ns = Ns Ar input-format , Fl b Ar input-format
-Specify the format of the inputs following this option.
-.Ar input-format
-may be one of
-.Cm binary ,
-.Cm elf ,
-and
-.Cm default .
-.Cm default
-is a synonym for
-.Cm elf .
-.It Fl -gc-sections
-Enable garbage collection of unused sections.
-.It Fl -gdb-index
-Generate
-.Li .gdb_index
-section.
-.It Fl -hash-style Ns = Ns Ar value
-Specify hash style.
-.Ar value
-may be
-.Cm sysv ,
-.Cm gnu ,
-or
-.Cm both .
-.Cm both
-is the default.
-.It Fl -help
-Print a help message.
-.It Fl -icf Ns = Ns Cm all
-Enable identical code folding.
-.It Fl -icf Ns = Ns Cm safe
-Enable safe identical code folding.
-.It Fl -icf Ns = Ns Cm none
-Disable identical code folding.
-.It Fl -ignore-data-address-equality
-Ignore address equality of data. C/C++ requires each data to have a unique
-address.
-This option allows lld to do unsafe optimization that breaks the
-requirement: create copies of read-only data or merge two or more read-only data
-that happen to have the same value.
-.It Fl -ignore-function-address-equality
-Ignore address equality of functions.
-This option allows non-PIC calls to a function with non-default visibility in
-a shared object.
-The function may have different addresses within the executable and within the
-shared object.
-.It Fl -image-base Ns = Ns Ar value
-Set the base address to
-.Ar value .
-.It Fl -init Ns = Ns Ar symbol
-Specify an initializer function.
-.It Fl -keep-unique Ns = Ns Ar symbol
-Do not fold
-.Ar symbol
-during ICF.
-.It Fl l Ar libName, Fl -library Ns = Ns Ar libName
-Root name of library to use.
-.It Fl L Ar dir , Fl -library-path Ns = Ns Ar dir
-Add a directory to the library search path.
-.It Fl -lto-aa-pipeline Ns = Ns Ar value
-AA pipeline to run during LTO.
-Used in conjunction with
-.Fl -lto-newpm-passes .
-.It Fl -lto-newpm-passes Ns = Ns Ar value
-Passes to run during LTO.
-.It Fl -lto-O Ns Ar opt-level
-Optimization level for LTO.
-.It Fl -lto-partitions Ns = Ns Ar value
-Number of LTO codegen partitions.
-.It Fl m Ar value
-Set target emulation.
-.It Fl -Map Ns = Ns Ar file , Fl M Ar file
-Print a link map to
-.Ar file .
-.It Fl -nmagic , Fl n
-Do not page align sections, link against static libraries.
-.It Fl -no-allow-shlib-undefined
-Do not allow unresolved references in shared libraries.
-This option is enabled by default when linking an executable.
-.It Fl -no-as-needed
-Always set
-.Dv DT_NEEDED
-for shared libraries.
-.It Fl -no-color-diagnostics
-Do not use colors in diagnostics.
-.It Fl -no-define-common
-Do not assign space to common symbols.
-.It Fl -no-demangle
-Do not demangle symbol names.
-.It Fl -no-dynamic-linker
-Inhibit output of an
-.Li .interp
-section.
-.It Fl -no-fortran-common
-Do not search archive members for definitions to override COMMON symbols.
-.It Fl -no-gc-sections
-Disable garbage collection of unused sections.
-.It Fl -no-gnu-unique
-Disable STB_GNU_UNIQUE symbol binding.
-.It Fl -no-merge-exidx-entries
-Disable merging .ARM.exidx entries.
-.It Fl -no-nmagic
-Page align sections.
-.It Fl -no-omagic
-Do not set the text data sections to be writable, page align sections.
-.It Fl -no-relax
-Disable target-specific relaxations. This is currently a no-op.
-.It Fl -no-rosegment
-Do not put read-only non-executable sections in their own segment.
-.It Fl -no-undefined-version
-Report version scripts that refer undefined symbols.
-.It Fl -no-undefined
-Report unresolved symbols even if the linker is creating a shared library.
-.It Fl -no-warn-symbol-ordering
-Do not warn about problems with the symbol ordering file or call graph profile.
-.It Fl -no-whole-archive
-Restores the default behavior of loading archive members.
-.It Fl -no-pie , Fl -no-pic-executable
-Do not create a position independent executable.
-.It Fl -noinhibit-exec
-Retain the executable output file whenever it is still usable.
-.It Fl -nostdlib
-Only search directories specified on the command line.
-.It Fl o Ar path
-Write the output executable, library, or object to
-.Ar path .
-If not specified,
-.Dv a.out
-is used as a default.
-.It Fl O Ns Ar value
-Optimize output file size.
-.Ar value
-may be:
-.Pp
-.Bl -tag -width 2n -compact
-.It Cm 0
-Disable string merging.
-.It Cm 1
-Enable string merging.
-.It Cm 2
-Enable string tail merging. If
-.Fl -compress-debug-sections
-is given, compress debug sections at compression level 6 instead of 1.
-.El
-.Pp
-.Fl O Ns Cm 1
-is the default.
-.It Fl -oformat Ns = Ns Ar format
-Specify the format for the output object file.
-The only supported
-.Ar format
-is
-.Cm binary ,
-which produces output with no ELF header.
-.It Fl -omagic , Fl N
-Set the text and data sections to be readable and writable, do not page align
-sections, link against static libraries.
-.It Fl -opt-remarks-filename Ar file
-Write optimization remarks in YAML format to
-.Ar file .
-.It Fl -opt-remarks-passes Ar pass-regex
-Filter optimization remarks by only allowing the passes matching
-.Ar pass-regex .
-.It Fl -opt-remarks-with-hotness
-Include hotness information in the optimization remarks file.
-.It Fl -orphan-handling Ns = Ns Ar mode
-Control how orphan sections are handled.
-An orphan section is one not specifically mentioned in a linker script.
-.Ar mode
-may be:
-.Pp
-.Bl -tag -width 2n -compact
-.It Cm place
-Place orphan sections in suitable output sections.
-.It Cm warn
-Place orphan sections as for
-.Cm place
-and also report a warning.
-.It Cm error
-Place orphan sections as for
-.Cm place
-and also report an error.
-.El
-.Pp
-.Cm place
-is the default.
-.It Fl -pack-dyn-relocs Ns = Ns Ar format
-Pack dynamic relocations in the given format.
-.Ar format
-may be:
-.Pp
-.Bl -tag -width 2n -compact
-.It Cm none
-Do not pack.
-Dynamic relocations are encoded in SHT_REL(A).
-.It Cm android
-Pack dynamic relocations in SHT_ANDROID_REL(A).
-.It Cm relr
-Pack relative relocations in SHT_RELR, and the rest of dynamic relocations in
-SHT_REL(A).
-.It Cm android+relr
-Pack relative relocations in SHT_RELR, and the rest of dynamic relocations in
-SHT_ANDROID_REL(A).
-.El
-.Pp
-.Cm none
-is the default.
-If
-.Fl -use-android-relr-tags
-is specified, use SHT_ANDROID_RELR instead of SHT_RELR.
-.Pp
-.It Fl -pic-veneer
-Always generate position independent thunks.
-.It Fl -pie , Fl -pic-executable
-Create a position independent executable.
-.It Fl -print-gc-sections
-List removed unused sections.
-.It Fl -print-icf-sections
-List identical folded sections.
-.It Fl -print-map
-Print a link map to the standard output.
-.It Fl -print-archive-stats Ns = Ns Ar file
-Write archive usage statistics to the specified file.
-Print the numbers of members and fetched members for each archive.
-.It Fl -push-state
-Save the current state of
-.Fl -as-needed ,
-.Fl -static ,
-and
-.Fl -whole-archive.
-.It Fl -pop-state
-Undo the effect of
-.Fl -push-state.
-.It Fl -relocatable , Fl r
-Create relocatable object file.
-.It Fl -reproduce Ns = Ns Ar path
-Write a tar file to
-.Ar path,
-containing all the input files needed to reproduce the link, a text file called
-response.txt containing the command line options and a text file called
-version.txt containing the output of ld.lld --version.
-The archive when
-unpacked can be used to re-run the linker with the same options and input files.
-.It Fl -retain-symbols-file Ns = Ns Ar file
-Retain only the symbols listed in the file.
-.It Fl -rpath Ns = Ns Ar value , Fl R Ar value
-Add a
-.Dv DT_RUNPATH
-to the output.
-.It Fl -rsp-quoting Ns = Ns Ar value
-Quoting style for response files.
-The supported values are
-.Cm windows
-and
-.Cm posix .
-.It Fl -script Ns = Ns Ar file , Fl T Ar file
-Read linker script from
-.Ar file .
-If multiple linker scripts are given, they are processed as if they
-were concatenated in the order they appeared on the command line.
-.It Fl -section-start Ns = Ns Ar section Ns = Ns Ar address
-Set address of section.
-.It Fl -shared , Fl -Bsharable
-Build a shared object.
-.It Fl -shuffle-sections Ns = Ns Ar seed
-Shuffle matched sections using the given seed before mapping them to the output sections.
-If -1, reverse the section order. If 0, use a random seed.
-.It Fl -soname Ns = Ns Ar value , Fl h Ar value
-Set
-.Dv DT_SONAME
-to
-.Ar value .
-.It Fl -sort-common
-This option is ignored for GNU compatibility.
-.It Fl -sort-section Ns = Ns Ar value
-Specifies sections sorting rule when linkerscript is used.
-.It Fl -start-lib
-Start a grouping of objects that should be treated as if they were together
-in an archive.
-.It Fl -strip-all , Fl s
-Strip all symbols.
-Implies
-.Fl -strip-debug .
-.It Fl -strip-debug , Fl S
-Strip debugging information.
-.It Fl -symbol-ordering-file Ns = Ns Ar file
-Lay out sections in the order specified by
-.Ar file .
-.It Fl -sysroot Ns = Ns Ar value
-Set the system root.
-.It Fl -target1-abs
-Interpret
-.Dv R_ARM_TARGET1
-as
-.Dv R_ARM_ABS32 .
-.It Fl -target1-rel
-Interpret
-.Dv R_ARM_TARGET1
-as
-.Dv R_ARM_REL32 .
-.It Fl -target2 Ns = Ns Ar type
-Interpret
-.Dv R_ARM_TARGET2
-as
-.Ar type ,
-where
-.Ar type
-is one of
-.Cm rel ,
-.Cm abs ,
-or
-.Cm got-rel .
-.It Fl -Tbss Ns = Ns Ar value
-Same as
-.Fl -section-start
-with
-.Li .bss
-as the sectionname.
-.It Fl -Tdata Ns = Ns Ar value
-Same as
-.Fl -section-start
-with
-.Li .data
-as the sectionname.
-.It Fl -Ttext Ns = Ns Ar value
-Same as
-.Fl -section-start
-with
-.Li .text
-as the sectionname.
-.It Fl -thinlto-cache-dir Ns = Ns Ar value
-Path to ThinLTO cached object file directory.
-.It Fl -thinlto-cache-policy Ns = Ns Ar value
-Pruning policy for the ThinLTO cache.
-.It Fl -thinlto-jobs Ns = Ns Ar value
-Number of ThinLTO jobs.
-.It Fl -threads Ns = Ns Ar N
-Number of threads.
-.Cm all
-(default) means all of concurrent threads supported.
-.Cm 1
-disables multi-threading.
-.It Fl -time-trace
-Record time trace.
-.It Fl -time-trace-file Ns = Ns Ar file
-Write time trace output to
-.Ar file .
-.It Fl -time-trace-granularity Ns = Ns Ar value
-Minimum time granularity (in microseconds) traced by time profiler.
-.It Fl -trace
-Print the names of the input files.
-.It Fl -trace-symbol Ns = Ns Ar symbol , Fl y Ar symbol
-Trace references to
-.Ar symbol .
-.It Fl -undefined Ns = Ns Ar symbol , Fl u Ar symbol
-If
-.Ar symbol
-is not defined after symbol resolution, and there's a static library
-that contains an object file defining the symbol, load the member
-to include the object file in the output file.
-.It Fl -undefined-glob Ns = Ns Ar pattern
-Synonym for
-.Fl -undefined ,
-except that it takes a glob pattern.
-In a glob pattern,
-.Cm *
-matches zero or more characters,
-.Cm ?
-matches any single character, and
-.Cm [...]
-matches the characters within brackets.
-All symbols that match
-a given pattern are handled as if they were given as arguments of
-.Fl -undefined .
-.It Fl -unique
-Creates a separate output section for every orphan input section.
-.It Fl -unresolved-symbols Ns = Ns Ar value
-Determine how to handle unresolved symbols.
-.It Fl -use-android-relr-tags
-Use SHT_ANDROID_RELR / DT_ANDROID_RELR* tags instead of SHT_RELR / DT_RELR*.
-.It Fl v
-Display the version number and proceed with linking if object files are
-specified.
-.It Fl V , Fl -version
-Display the version number and exit.
-.It Fl -verbose
-Verbose mode.
-.It Fl -version-script Ns = Ns Ar file
-Read version script from
-.Ar file .
-.It Fl -warn-backrefs
-Warn about reverse or cyclic dependencies to or between static archives.
-This can be used to ensure linker invocation remains compatible with
-traditional Unix-like linkers.
-.It Fl -warn-backrefs-exclude Ns = Ns Ar glob
-Glob describing an archive (or an object file within --start-lib)
-which should be ignored for
-.Fl -warn-backrefs
-.It Fl -warn-common
-Warn about duplicate common symbols.
-.It Fl -warn-ifunc-textrel
-Warn about using ifunc symbols in conjunction with text relocations.
-Older versions of glibc library (2.28 and earlier) has a bug that causes
-the segment that includes ifunc symbols to be marked as not executable when
-they are relocated.
-As a result, although the program compiles and links
-successfully, it gives segmentation fault when the instruction pointer reaches
-an ifunc symbol.
-Use -warn-ifunc-textrel to let lld give a warning, if the
-code may include ifunc symbols, may do text relocations and be linked with
-an older glibc version.
-Otherwise, there is no need to use it, as the default value does not give a
-warning.
-This flag has been introduced in late 2018, has no counter part in ld and gold
-linkers, and may be removed in the future.
-.It Fl -warn-unresolved-symbols
-Report unresolved symbols as warnings.
-.It Fl -whole-archive
-Force load of all members in a static library.
-.It Fl -wrap Ns = Ns Ar symbol
-Redirect
-.Ar symbol
-references to
-.Ar __wrap_symbol
-and
-.Ar __real_symbol
-references to
-.Ar symbol.
-.It Fl z Ar option
-Linker option extensions.
-.Bl -tag -width indent -compact
-.Pp
-.It Cm dead-reloc-in-nonalloc Ns = Ns Ar section_glob=value
-Resolve a relocation in a matched non-SHF_ALLOC section referencing a discarded symbol to
-.Ar value
-Accepts globs, in the event of a section matching more than one option, the last
-option takes precedence. An order of least specific to most specific match is
-recommended.
-.Pp
-.It Cm execstack
-Make the main stack executable.
-Stack permissions are recorded in the
-.Dv PT_GNU_STACK
-segment.
-.Pp
-.It Cm force-bti
-Force enable AArch64 BTI instruction in PLT, warn if Input ELF file does not have GNU_PROPERTY_AARCH64_FEATURE_1_BTI property.
-.Pp
-.It Cm force-ibt
-Force enable Intel Indirect Branch Tracking in PLT, warn if an input ELF file
-does not have GNU_PROPERTY_X86_FEATURE_1_IBT property.
-.Pp
-.It Cm global
-Sets the
-.Dv DF_1_GLOBAL flag in the
-.Dv DYNAMIC
-section.
-Different loaders can decide how to handle this flag on their own.
-.Pp
-.It Cm ifunc-noplt
-Do not emit PLT entries for ifunc symbols.
-Instead, emit text relocations referencing the resolver.
-This is an experimental optimization and only suitable for standalone
-environments where text relocations do not have the usual drawbacks.
-This option must be combined with the
-.Fl z Li notext
-option.
-.Pp
-.It Cm initfirst
-Sets the
-.Dv DF_1_INITFIRST
-flag to indicate the module should be initialized first.
-.Pp
-.It Cm interpose
-Set the
-.Dv DF_1_INTERPOSE
-flag to indicate to the runtime linker that the object is an interposer.
-During symbol resolution interposers are searched after the application
-but before other dependencies.
-.Pp
-.It Cm muldefs
-Do not error if a symbol is defined multiple times.
-The first definition will be used.
-This is a synonym for
-.Fl -allow-multiple-definition.
-.Pp
-.It Cm nocombreloc
-Disable combining and sorting multiple relocation sections.
-.Pp
-.It Cm nocopyreloc
-Disable the creation of copy relocations.
-.Pp
-.It Cm nodefaultlib
-Set the
-.Dv DF_1_NODEFLIB
-flag to indicate that default library search paths should be ignored.
-.Pp
-.It Cm nodelete
-Set the
-.Dv DF_1_NODELETE
-flag to indicate that the object cannot be unloaded from a process.
-.Pp
-.It Cm nodlopen
-Set the
-.Dv DF_1_NOOPEN
-flag to indicate that the object may not be opened by
-.Xr dlopen 3 .
-.Pp
-.It Cm nognustack
-Do not emit the
-.Dv PT_GNU_STACK
-segment.
-.Pp
-.It Cm norelro
-Do not indicate that portions of the object should be mapped read-only
-after initial relocation processing.
-The object will omit the
-.Dv PT_GNU_RELRO
-segment.
-.Pp
-.It Cm notext
-Allow relocations against read-only segments.
-Sets the
-.Dv DT_TEXTREL flag in the
-.Dv DYNAMIC
-section.
-.Pp
-.It Cm now
-Set the
-.Dv DF_BIND_NOW
-flag to indicate that the run-time loader should perform all relocation
-processing as part of object initialization.
-By default relocations may be performed on demand.
-.Pp
-.It Cm origin
-Set the
-.Dv DF_ORIGIN
-flag to indicate that the object requires
-$ORIGIN
-processing.
-.Pp
-.It Cm pac-plt
-AArch64 only, use pointer authentication in PLT.
-.Pp
-.It Cm rel
-Use REL format for dynamic relocations.
-.Pp
-.It Cm rela
-Use RELA format for dynamic relocations.
-.Pp
-.It Cm retpolineplt
-Emit retpoline format PLT entries as a mitigation for CVE-2017-5715.
-.Pp
-.It Cm rodynamic
-Make the
-.Li .dynamic
-section read-only.
-The
-.Dv DT_DEBUG
-tag will not be emitted.
-.Pp
-.It Cm separate-loadable-segments
-.It Cm separate-code
-.It Cm noseparate-code
-Specify whether two adjacent PT_LOAD segments are allowed to overlap in pages.
-.Cm noseparate-code
-(default) allows overlap.
-.Cm separate-code
-allows overlap between two executable segments, or two non-executable segments.
-.Cm separate-loadable-segments
-disallows overlap.
-.Pp
-.It Cm shstk
-x86 only, use shadow stack.
-.Pp
-.It Cm stack-size Ns = Ns Ar size
-Set the main thread's stack size to
-.Ar size .
-The stack size is recorded as the size of the
-.Ar size .
-.Dv PT_GNU_STACK
-program segment.
-.Pp
-.It Cm start-stop-gc
-Don't let __start_/__stop_ references retain the associated C identifier name sections (default).
-.Pp
-.It Cm nostart-stop-gc
-Let __start_/__stop_ references retain the associated C identifier name sections.
-.Pp
-.It Cm text
-Do not allow relocations against read-only segments.
-This is the default.
-.Pp
-.It Cm wxneeded
-Create a
-.Dv PT_OPENBSD_WXNEEDED
-segment.
-.El
-.El
-.Sh IMPLEMENTATION NOTES
-.Nm Ap s
-handing of archive files (those with a
-.Pa .a
-file extension) is different from traditional linkers used on Unix-like
-systems.
-.Pp
-Traditional linkers maintain a set of undefined symbols during linking.
-The linker processes each file in the order in which it appears on the
-command line, until the set of undefined symbols becomes empty.
-An object file is linked into the output object when it is encountered,
-with its undefined symbols added to the set.
-Upon encountering an archive file a traditional linker searches the objects
-contained therein, and processes those that satisfy symbols in the unresolved
-set.
-.Pp
-Handling mutually dependent archives may be awkward when using a traditional
-linker.
-Archive files may have to be specified multiple times, or the special command
-line options
-.Fl -start-group
-and
-.Fl -end-group
-may be used to have the linker loop over the files in the group until no new
-symbols are added to the set.
-.Pp
-.Nm
-records all symbols found in objects and archives as it iterates over
-command line arguments.
-When
-.Nm
-encounters an undefined symbol that can be resolved by an object file
-contained in a previously processed archive file, it immediately extracts
-and links it into the output object.
-.Pp
-With certain archive inputs
-.Nm
-may produce different results compared to traditional linkers.
-In practice, large bodies of third party software have been linked with
-.Nm
-without material issues.
-.Pp
-The
-.Fl -warn-backrefs
-option may be used to identify a linker invocation that may be incompatible
-with traditional Unix-like linker behavior.
diff --git a/lld/docs/llvm-theme/layout.html b/lld/docs/llvm-theme/layout.html
deleted file mode 100644
index 0cd0918eac..0000000000
--- a/lld/docs/llvm-theme/layout.html
+++ /dev/null
@@ -1,22 +0,0 @@
-{#
- sphinxdoc/layout.html
- ~~~~~~~~~~~~~~~~~~~~~
-
- Sphinx layout template for the sphinxdoc theme.
-
- :copyright: Copyright 2007-2010 by the Sphinx team, see AUTHORS.
- :license: BSD, see LICENSE for details.
-#}
-{% extends "basic/layout.html" %}
-
-{% block relbar1 %}
-
-
-
-{{ super() }}
-{% endblock %}
-
-{# put the sidebar before the body #}
-{% block sidebar1 %}{{ sidebar() }}{% endblock %}
-{% block sidebar2 %}{% endblock %}
diff --git a/lld/docs/llvm-theme/static/contents.png b/lld/docs/llvm-theme/static/contents.png
deleted file mode 100644
index 7fb82154a1..0000000000
Binary files a/lld/docs/llvm-theme/static/contents.png and /dev/null differ
diff --git a/lld/docs/llvm-theme/static/llvm.css b/lld/docs/llvm-theme/static/llvm.css
deleted file mode 100644
index 32802bb6a2..0000000000
--- a/lld/docs/llvm-theme/static/llvm.css
+++ /dev/null
@@ -1,345 +0,0 @@
-/*
- * sphinxdoc.css_t
- * ~~~~~~~~~~~~~~~
- *
- * Sphinx stylesheet -- sphinxdoc theme. Originally created by
- * Armin Ronacher for Werkzeug.
- *
- * :copyright: Copyright 2007-2010 by the Sphinx team, see AUTHORS.
- * :license: BSD, see LICENSE for details.
- *
- */
-
-@import url("basic.css");
-
-/* -- page layout ----------------------------------------------------------- */
-
-body {
- font-family: 'Lucida Grande', 'Lucida Sans Unicode', 'Geneva',
- 'Verdana', sans-serif;
- font-size: 14px;
- letter-spacing: -0.01em;
- line-height: 150%;
- text-align: center;
- background-color: #BFD1D4;
- color: black;
- padding: 0;
- border: 1px solid #aaa;
-
- margin: 0px 80px 0px 80px;
- min-width: 740px;
-}
-
-div.logo {
- background-color: white;
- text-align: left;
- padding: 10px 10px 15px 15px;
-}
-
-div.document {
- background-color: white;
- text-align: left;
- background-image: url(contents.png);
- background-repeat: repeat-x;
-}
-
-div.bodywrapper {
- margin: 0 240px 0 0;
- border-right: 1px solid #ccc;
-}
-
-div.body {
- margin: 0;
- padding: 0.5em 20px 20px 20px;
-}
-
-div.related {
- font-size: 1em;
-}
-
-div.related ul {
- background-image: url(navigation.png);
- height: 2em;
- border-top: 1px solid #ddd;
- border-bottom: 1px solid #ddd;
-}
-
-div.related ul li {
- margin: 0;
- padding: 0;
- height: 2em;
- float: left;
-}
-
-div.related ul li.right {
- float: right;
- margin-right: 5px;
-}
-
-div.related ul li a {
- margin: 0;
- padding: 0 5px 0 5px;
- line-height: 1.75em;
- color: #EE9816;
-}
-
-div.related ul li a:hover {
- color: #3CA8E7;
-}
-
-div.sphinxsidebarwrapper {
- padding: 0;
-}
-
-div.sphinxsidebar {
- margin: 0;
- padding: 0.5em 15px 15px 0;
- width: 210px;
- float: right;
- font-size: 1em;
- text-align: left;
-}
-
-div.sphinxsidebar h3, div.sphinxsidebar h4 {
- margin: 1em 0 0.5em 0;
- font-size: 1em;
- padding: 0.1em 0 0.1em 0.5em;
- color: white;
- border: 1px solid #86989B;
- background-color: #AFC1C4;
-}
-
-div.sphinxsidebar h3 a {
- color: white;
-}
-
-div.sphinxsidebar ul {
- padding-left: 1.5em;
- margin-top: 7px;
- padding: 0;
- line-height: 130%;
-}
-
-div.sphinxsidebar ul ul {
- margin-left: 20px;
-}
-
-div.footer {
- background-color: #E3EFF1;
- color: #86989B;
- padding: 3px 8px 3px 0;
- clear: both;
- font-size: 0.8em;
- text-align: right;
-}
-
-div.footer a {
- color: #86989B;
- text-decoration: underline;
-}
-
-/* -- body styles ----------------------------------------------------------- */
-
-p {
- margin: 0.8em 0 0.5em 0;
-}
-
-a {
- color: #CA7900;
- text-decoration: none;
-}
-
-a:hover {
- color: #2491CF;
-}
-
-div.body a {
- text-decoration: underline;
-}
-
-h1 {
- margin: 0;
- padding: 0.7em 0 0.3em 0;
- font-size: 1.5em;
- color: #11557C;
-}
-
-h2 {
- margin: 1.3em 0 0.2em 0;
- font-size: 1.35em;
- padding: 0;
-}
-
-h3 {
- margin: 1em 0 -0.3em 0;
- font-size: 1.2em;
-}
-
-div.body h1 a, div.body h2 a, div.body h3 a, div.body h4 a, div.body h5 a, div.body h6 a {
- color: black!important;
-}
-
-h1 a.anchor, h2 a.anchor, h3 a.anchor, h4 a.anchor, h5 a.anchor, h6 a.anchor {
- display: none;
- margin: 0 0 0 0.3em;
- padding: 0 0.2em 0 0.2em;
- color: #aaa!important;
-}
-
-h1:hover a.anchor, h2:hover a.anchor, h3:hover a.anchor, h4:hover a.anchor,
-h5:hover a.anchor, h6:hover a.anchor {
- display: inline;
-}
-
-h1 a.anchor:hover, h2 a.anchor:hover, h3 a.anchor:hover, h4 a.anchor:hover,
-h5 a.anchor:hover, h6 a.anchor:hover {
- color: #777;
- background-color: #eee;
-}
-
-a.headerlink {
- color: #c60f0f!important;
- font-size: 1em;
- margin-left: 6px;
- padding: 0 4px 0 4px;
- text-decoration: none!important;
-}
-
-a.headerlink:hover {
- background-color: #ccc;
- color: white!important;
-}
-
-cite, code, tt {
- font-family: 'Consolas', 'Deja Vu Sans Mono',
- 'Bitstream Vera Sans Mono', monospace;
- font-size: 0.95em;
- letter-spacing: 0.01em;
-}
-
-tt {
- background-color: #f2f2f2;
- border-bottom: 1px solid #ddd;
- color: #333;
-}
-
-tt.descname, tt.descclassname, tt.xref {
- border: 0;
-}
-
-hr {
- border: 1px solid #abc;
- margin: 2em;
-}
-
-a tt {
- border: 0;
- color: #CA7900;
-}
-
-a tt:hover {
- color: #2491CF;
-}
-
-pre {
- font-family: 'Consolas', 'Deja Vu Sans Mono',
- 'Bitstream Vera Sans Mono', monospace;
- font-size: 0.95em;
- letter-spacing: 0.015em;
- line-height: 120%;
- padding: 0.5em;
- border: 1px solid #ccc;
- background-color: #f8f8f8;
-}
-
-pre a {
- color: inherit;
- text-decoration: underline;
-}
-
-td.linenos pre {
- padding: 0.5em 0;
-}
-
-div.quotebar {
- background-color: #f8f8f8;
- max-width: 250px;
- float: right;
- padding: 2px 7px;
- border: 1px solid #ccc;
-}
-
-div.topic {
- background-color: #f8f8f8;
-}
-
-table {
- border-collapse: collapse;
- margin: 0 -0.5em 0 -0.5em;
-}
-
-table td, table th {
- padding: 0.2em 0.5em 0.2em 0.5em;
-}
-
-div.admonition, div.warning {
- font-size: 0.9em;
- margin: 1em 0 1em 0;
- border: 1px solid #86989B;
- background-color: #f7f7f7;
- padding: 0;
-}
-
-div.admonition p, div.warning p {
- margin: 0.5em 1em 0.5em 1em;
- padding: 0;
-}
-
-div.admonition pre, div.warning pre {
- margin: 0.4em 1em 0.4em 1em;
-}
-
-div.admonition p.admonition-title,
-div.warning p.admonition-title {
- margin: 0;
- padding: 0.1em 0 0.1em 0.5em;
- color: white;
- border-bottom: 1px solid #86989B;
- font-weight: bold;
- background-color: #AFC1C4;
-}
-
-div.warning {
- border: 1px solid #940000;
-}
-
-div.warning p.admonition-title {
- background-color: #CF0000;
- border-bottom-color: #940000;
-}
-
-div.admonition ul, div.admonition ol,
-div.warning ul, div.warning ol {
- margin: 0.1em 0.5em 0.5em 3em;
- padding: 0;
-}
-
-div.versioninfo {
- margin: 1em 0 0 0;
- border: 1px solid #ccc;
- background-color: #DDEAF0;
- padding: 8px;
- line-height: 1.3em;
- font-size: 0.9em;
-}
-
-.viewcode-back {
- font-family: 'Lucida Grande', 'Lucida Sans Unicode', 'Geneva',
- 'Verdana', sans-serif;
-}
-
-div.viewcode-block:target {
- background-color: #f4debf;
- border-top: 1px solid #ac9;
- border-bottom: 1px solid #ac9;
-}
diff --git a/lld/docs/llvm-theme/static/logo.png b/lld/docs/llvm-theme/static/logo.png
deleted file mode 100644
index 4fc899028d..0000000000
Binary files a/lld/docs/llvm-theme/static/logo.png and /dev/null differ
diff --git a/lld/docs/llvm-theme/static/navigation.png b/lld/docs/llvm-theme/static/navigation.png
deleted file mode 100644
index 1081dc1439..0000000000
Binary files a/lld/docs/llvm-theme/static/navigation.png and /dev/null differ
diff --git a/lld/docs/llvm-theme/theme.conf b/lld/docs/llvm-theme/theme.conf
deleted file mode 100644
index 330fc92ffa..0000000000
--- a/lld/docs/llvm-theme/theme.conf
+++ /dev/null
@@ -1,4 +0,0 @@
-[theme]
-inherit = basic
-stylesheet = llvm.css
-pygments_style = friendly
diff --git a/lld/docs/make.bat b/lld/docs/make.bat
deleted file mode 100644
index 8471252d70..0000000000
--- a/lld/docs/make.bat
+++ /dev/null
@@ -1,190 +0,0 @@
-@ECHO OFF
-
-REM Command file for Sphinx documentation
-
-if "%SPHINXBUILD%" == "" (
- set SPHINXBUILD=sphinx-build
-)
-set BUILDDIR=_build
-set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% .
-set I18NSPHINXOPTS=%SPHINXOPTS% .
-if NOT "%PAPER%" == "" (
- set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%
- set I18NSPHINXOPTS=-D latex_paper_size=%PAPER% %I18NSPHINXOPTS%
-)
-
-if "%1" == "" goto help
-
-if "%1" == "help" (
- :help
- echo.Please use `make ^` where ^ is one of
- echo. html to make standalone HTML files
- echo. dirhtml to make HTML files named index.html in directories
- echo. singlehtml to make a single large HTML file
- echo. pickle to make pickle files
- echo. json to make JSON files
- echo. htmlhelp to make HTML files and a HTML help project
- echo. qthelp to make HTML files and a qthelp project
- echo. devhelp to make HTML files and a Devhelp project
- echo. epub to make an epub
- echo. latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter
- echo. text to make text files
- echo. man to make manual pages
- echo. texinfo to make Texinfo files
- echo. gettext to make PO message catalogs
- echo. changes to make an overview over all changed/added/deprecated items
- echo. linkcheck to check all external links for integrity
- echo. doctest to run all doctests embedded in the documentation if enabled
- goto end
-)
-
-if "%1" == "clean" (
- for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i
- del /q /s %BUILDDIR%\*
- goto end
-)
-
-if "%1" == "html" (
- %SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished. The HTML pages are in %BUILDDIR%/html.
- goto end
-)
-
-if "%1" == "dirhtml" (
- %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml.
- goto end
-)
-
-if "%1" == "singlehtml" (
- %SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml.
- goto end
-)
-
-if "%1" == "pickle" (
- %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished; now you can process the pickle files.
- goto end
-)
-
-if "%1" == "json" (
- %SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished; now you can process the JSON files.
- goto end
-)
-
-if "%1" == "htmlhelp" (
- %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished; now you can run HTML Help Workshop with the ^
-.hhp project file in %BUILDDIR%/htmlhelp.
- goto end
-)
-
-if "%1" == "qthelp" (
- %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished; now you can run "qcollectiongenerator" with the ^
-.qhcp project file in %BUILDDIR%/qthelp, like this:
- echo.^> qcollectiongenerator %BUILDDIR%\qthelp\lld.qhcp
- echo.To view the help file:
- echo.^> assistant -collectionFile %BUILDDIR%\qthelp\lld.ghc
- goto end
-)
-
-if "%1" == "devhelp" (
- %SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished.
- goto end
-)
-
-if "%1" == "epub" (
- %SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished. The epub file is in %BUILDDIR%/epub.
- goto end
-)
-
-if "%1" == "latex" (
- %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished; the LaTeX files are in %BUILDDIR%/latex.
- goto end
-)
-
-if "%1" == "text" (
- %SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished. The text files are in %BUILDDIR%/text.
- goto end
-)
-
-if "%1" == "man" (
- %SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished. The manual pages are in %BUILDDIR%/man.
- goto end
-)
-
-if "%1" == "texinfo" (
- %SPHINXBUILD% -b texinfo %ALLSPHINXOPTS% %BUILDDIR%/texinfo
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished. The Texinfo files are in %BUILDDIR%/texinfo.
- goto end
-)
-
-if "%1" == "gettext" (
- %SPHINXBUILD% -b gettext %I18NSPHINXOPTS% %BUILDDIR%/locale
- if errorlevel 1 exit /b 1
- echo.
- echo.Build finished. The message catalogs are in %BUILDDIR%/locale.
- goto end
-)
-
-if "%1" == "changes" (
- %SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes
- if errorlevel 1 exit /b 1
- echo.
- echo.The overview file is in %BUILDDIR%/changes.
- goto end
-)
-
-if "%1" == "linkcheck" (
- %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck
- if errorlevel 1 exit /b 1
- echo.
- echo.Link check complete; look for any errors in the above output ^
-or in %BUILDDIR%/linkcheck/output.txt.
- goto end
-)
-
-if "%1" == "doctest" (
- %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest
- if errorlevel 1 exit /b 1
- echo.
- echo.Testing of doctests in the sources finished, look at the ^
-results in %BUILDDIR%/doctest/output.txt.
- goto end
-)
-
-:end
diff --git a/lld/docs/missingkeyfunction.rst b/lld/docs/missingkeyfunction.rst
deleted file mode 100644
index db4ea11b4a..0000000000
--- a/lld/docs/missingkeyfunction.rst
+++ /dev/null
@@ -1,85 +0,0 @@
-Missing Key Function
-====================
-
-If your build failed with a linker error something like this::
-
- foo.cc:28: error: undefined reference to 'vtable for C'
- the vtable symbol may be undefined because the class is missing its key function
- (see https://lld.llvm.org/missingkeyfunction)
-
-it's likely that your class C has a key function (defined by the ABI as the first
-non-pure, non-inline, virtual function), but you haven't actually defined it.
-
-When a class has a key function, the compiler emits the vtable (and some other
-things as well) only in the translation unit that defines that key function. Thus,
-if you're missing the key function, you'll also be missing the vtable. If no other
-function calls your missing function, you won't see any undefined reference errors
-for it, but you will see undefined references to the vtable symbol.
-
-When a class has no non-pure, non-inline, virtual functions, there is no key
-function, and the compiler is forced to emit the vtable in every translation unit
-that references the class. In this case, it is emitted in a COMDAT section,
-which allows the linker to eliminate all duplicate copies. This is still
-wasteful in terms of object file size and link time, so it's always advisable to
-ensure there is at least one eligible function that can serve as the key function.
-
-Here are the most common mistakes that lead to this error:
-
-Failing to define a virtual destructor
---------------------------------------
-
-Say you have a base class declared in a header file::
-
- class B {
- public:
- B();
- virtual ~B();
- ...
- };
-
-Here, ``~B`` is the first non-pure, non-inline, virtual function, so it is the key
-function. If you forget to define ``B::~B`` in your source file, the compiler will
-not emit the vtable for ``B``, and you'll get an undefined reference to "vtable
-for B".
-
-This is just an example of the more general mistake of forgetting to define the
-key function, but it's quite common because virtual destructors are likely to be
-the first eligible key function and it's easy to forget to implement them. It's
-also more likely that you won't have any direct references to the destructor, so
-you won't see any undefined reference errors that point directly to the problem.
-
-The solution in this case is to implement the missing function.
-
-Forgetting to declare a virtual function in an abstract class as pure
----------------------------------------------------------------------
-
-Say you have an abstract base class declared in a header file::
-
- class A {
- public:
- A();
- virtual ~A() {}
- virtual int foo() = 0;
- ...
- virtual int bar();
- ...
- };
-
-This base class is intended to be abstract, but you forgot to mark one of the
-functions pure. Here, ``A::bar``, being non-pure, is nominated as the key function,
-and as a result, the vtable for ``A`` is not emitted, because the compiler is
-waiting for a translation unit that defines ``A::bar``.
-
-The solution in this case is to add the missing ``= 0`` to the declaration of
-``A::bar``.
-
-Key function is defined, but the linker doesn't see it
-------------------------------------------------------
-
-It's also possible that you have defined the key function somewhere, but the
-object file containing the definition of that function isn't being linked into
-your application.
-
-The solution in this case is to check your dependencies to make sure that
-the object file or the library file containing the key function is given to
-the linker.
diff --git a/lld/docs/open_projects.rst b/lld/docs/open_projects.rst
deleted file mode 100644
index 36edca4e96..0000000000
--- a/lld/docs/open_projects.rst
+++ /dev/null
@@ -1,9 +0,0 @@
-.. _open_projects:
-
-Open Projects
-=============
-
-Documentation TODOs
-~~~~~~~~~~~~~~~~~~~
-
-.. todolist::
diff --git a/lld/docs/partitions.dot b/lld/docs/partitions.dot
deleted file mode 100644
index 81f12a2f42..0000000000
--- a/lld/docs/partitions.dot
+++ /dev/null
@@ -1,22 +0,0 @@
-digraph G {
- part_main [label="Main partition",shape=plaintext];
- part1 [label="Loadable partition 1",shape=plaintext];
- part2 [label="Loadable partition 2",shape=plaintext];
- main [style=filled,fillcolor=lightblue];
- f1 [style=filled,fillcolor=lightsalmon];
- f2 [style=filled,fillcolor=palegreen];
- f3 [style=filled,fillcolor=lightblue];
- f4 [style=filled,fillcolor=lightsalmon];
- f5 [style=filled,fillcolor=lightblue];
- f6 [style=filled,fillcolor=palegreen];
- part_main -> main;
- main -> f3;
- part1 -> f1;
- f1 -> f3;
- f1 -> f4;
- f1 -> f5;
- part2 -> f2;
- f2 -> f3;
- f2 -> f5;
- f2 -> f6;
-}
diff --git a/lld/docs/partitions.svg b/lld/docs/partitions.svg
deleted file mode 100644
index 39cd969334..0000000000
--- a/lld/docs/partitions.svg
+++ /dev/null
@@ -1,110 +0,0 @@
-
-
-
-
-
diff --git a/lld/docs/sphinx_intro.rst b/lld/docs/sphinx_intro.rst
deleted file mode 100644
index b671cdc3df..0000000000
--- a/lld/docs/sphinx_intro.rst
+++ /dev/null
@@ -1,127 +0,0 @@
-.. _sphinx_intro:
-
-Sphinx Introduction for LLVM Developers
-=======================================
-
-This document is intended as a short and simple introduction to the Sphinx
-documentation generation system for LLVM developers.
-
-Quickstart
-----------
-
-To get started writing documentation, you will need to:
-
- 1. Have the Sphinx tools :ref:`installed `.
-
- 2. Understand how to :ref:`build the documentation
- `.
-
- 3. Start :ref:`writing documentation `!
-
-.. _installing_sphinx:
-
-Installing Sphinx
-~~~~~~~~~~~~~~~~~
-
-You should be able to install Sphinx using the standard Python package
-installation tool ``easy_install``, as follows::
-
- $ sudo easy_install sphinx
- Searching for sphinx
- Reading http://pypi.python.org/simple/sphinx/
- Reading http://sphinx.pocoo.org/
- Best match: Sphinx 1.1.3
- ... more lines here ..
-
-If you do not have root access (or otherwise want to avoid installing Sphinx in
-system directories) see the section on :ref:`installing_sphinx_in_a_venv` .
-
-If you do not have the ``easy_install`` tool on your system, you should be able
-to install it using:
-
- Linux
- Use your distribution's standard package management tool to install it,
- i.e., ``apt-get install easy_install`` or ``yum install easy_install``.
-
- macOS
- All modern macOS systems come with ``easy_install`` as part of the base
- system.
-
- Windows
- See the `setuptools `_ package web
- page for instructions.
-
-
-.. _building_the_documentation:
-
-Building the documentation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-In order to build the documentation need to add ``-DLLVM_ENABLE_SPHINX=ON`` to
-your ``cmake`` command. Once you do this you can build the docs using
-``docs-lld-html`` build (``ninja`` or ``make``) target.
-
-That build target will invoke ``sphinx-build`` with the appropriate options for
-the project, and generate the HTML documentation in a ``tools/lld/docs/html``
-subdirectory.
-
-.. _writing_documentation:
-
-Writing documentation
-~~~~~~~~~~~~~~~~~~~~~
-
-The documentation itself is written in the reStructuredText (ReST) format, and
-Sphinx defines additional tags to support features like cross-referencing.
-
-The ReST format itself is organized around documents mostly being readable
-plaintext documents. You should generally be able to write new documentation
-easily just by following the style of the existing documentation.
-
-If you want to understand the formatting of the documents more, the best place
-to start is Sphinx's own `ReST Primer `_.
-
-
-Learning More
--------------
-
-If you want to learn more about the Sphinx system, the best place to start is
-the Sphinx documentation itself, available `here
-`_.
-
-
-.. _installing_sphinx_in_a_venv:
-
-Installing Sphinx in a Virtual Environment
-------------------------------------------
-
-Most Python developers prefer to work with tools inside a *virtualenv* (virtual
-environment) instance, which functions as an application sandbox. This avoids
-polluting your system installation with different packages used by various
-projects (and ensures that dependencies for different packages don't conflict
-with one another). Of course, you need to first have the virtualenv software
-itself which generally would be installed at the system level::
-
- $ sudo easy_install virtualenv
-
-but after that you no longer need to install additional packages in the system
-directories.
-
-Once you have the *virtualenv* tool itself installed, you can create a
-virtualenv for Sphinx using::
-
- $ virtualenv ~/my-sphinx-install
- New python executable in /Users/dummy/my-sphinx-install/bin/python
- Installing setuptools............done.
- Installing pip...............done.
-
- $ ~/my-sphinx-install/bin/easy_install sphinx
- ... install messages here ...
-
-and from now on you can "activate" the *virtualenv* using::
-
- $ source ~/my-sphinx-install/bin/activate
-
-which will change your PATH to ensure the sphinx-build tool from inside the
-virtual environment will be used. See the `virtualenv website
-`_ for more information on using
-virtual environments.
diff --git a/lld/docs/windows_support.rst b/lld/docs/windows_support.rst
deleted file mode 100644
index 620040ee81..0000000000
--- a/lld/docs/windows_support.rst
+++ /dev/null
@@ -1,97 +0,0 @@
-.. raw:: html
-
-
-
-.. role:: none
-.. role:: partial
-.. role:: good
-
-===============
-Windows support
-===============
-
-LLD supports Windows operating system. When invoked as ``lld-link.exe`` or with
-``-flavor link``, the driver for Windows operating system is used to parse
-command line options, and it drives further linking processes. LLD accepts
-almost all command line options that the linker shipped with Microsoft Visual
-C++ (link.exe) supports.
-
-The current status is that LLD is used to link production builds of large
-real-world binaries such as Firefox and Chromium.
-
-Development status
-==================
-
-Driver
- :good:`Mostly done`. Some exotic command line options that are not usually
- used for application development, such as ``/DRIVER``, are not supported.
-
-Linking against DLL
- :good:`Done`. LLD can read import libraries needed to link against DLL. Both
- export-by-name and export-by-ordinal are supported.
-
-Linking against static library
- :good:`Done`. The format of static library (.lib) on Windows is actually the
- same as on Unix (.a). LLD can read it.
-
-Creating DLL
- :good:`Done`. LLD creates a DLL if ``/DLL`` option is given. Exported
- functions can be specified either via command line (``/EXPORT``) or via
- module-definition file (.def). Both export-by-name and export-by-ordinal are
- supported.
-
-Windows resource files support
- :good:`Done`. If an ``.res`` file is given, LLD converts the file to a COFF
- file using LLVM's Object library.
-
-Safe Structured Exception Handler (SEH)
- :good:`Done` for both x86 and x64.
-
-Module-definition file
- :partial:`Partially done`. LLD currently recognizes these directives:
- ``EXPORTS``, ``HEAPSIZE``, ``STACKSIZE``, ``NAME``, and ``VERSION``.
-
-Debug info
- :good:`Done`. LLD can emit PDBs that are at parity with those generated by
- link.exe. However, LLD does not support /DEBUG:FASTLINK.
-
-
-Downloading LLD
-===============
-
-The Windows version of LLD is included in the `pre-built binaries of LLVM's
-releases `_ and in the `LLVM Snapshot
-Builds `_.
-
-Building LLD
-============
-
-Using Visual Studio IDE/MSBuild
--------------------------------
-
-1. Check out LLVM and LLD from the LLVM SVN repository (or Git mirror),
-#. run ``cmake -G "Visual Studio 12" `` from VS command prompt,
-#. open LLVM.sln with Visual Studio, and
-#. build ``lld`` target in ``lld executables`` folder
-
-Alternatively, you can use msbuild if you don't like to work in an IDE::
-
- msbuild LLVM.sln /m /target:"lld executables\lld"
-
-MSBuild.exe had been shipped as a component of the .NET framework, but since
-2013 it's part of Visual Studio. You can find it at "C:\\Program Files
-(x86)\\msbuild".
-
-You can build LLD as a 64 bit application. To do that, open VS2013 x64 command
-prompt and run cmake for "Visual Studio 12 Win64" target.
-
-Using Ninja
------------
-
-1. Check out LLVM and LLD from the LLVM SVN repository (or Git mirror),
-#. run ``cmake -G ninja `` from VS command prompt,
-#. run ``ninja lld``
diff --git a/llvm/cmake/modules/HandleLLVMOptions.cmake b/llvm/cmake/modules/HandleLLVMOptions.cmake
index 0c3419390c..cfcbb8f8ae 100644
--- a/llvm/cmake/modules/HandleLLVMOptions.cmake
+++ b/llvm/cmake/modules/HandleLLVMOptions.cmake
@@ -316,12 +316,11 @@ if( LLVM_ENABLE_PIC )
# Note: GCC<10.3 has a bug on SystemZ.
#
# Note: Clang allows IPO for -fPIC so this optimization is less effective.
- # Older Clang may support -fno-semantic-interposition but it used local
- # aliases to optimize global variables, which is incompatible with copy
- # relocations due to -fno-pic.
+ # Clang 13 has a bug related to -fsanitize-coverage
+ # -fno-semantic-interposition (https://reviews.llvm.org/D117183).
if ((CMAKE_COMPILER_IS_GNUCXX AND
NOT (LLVM_NATIVE_ARCH STREQUAL "SystemZ" AND CMAKE_CXX_COMPILER_VERSION VERSION_LESS 10.3))
- OR (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND CMAKE_CXX_COMPILER_VERSION GREATER_EQUAL 13))
+ OR (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND CMAKE_CXX_COMPILER_VERSION GREATER_EQUAL 14))
add_flag_if_supported("-fno-semantic-interposition" FNO_SEMANTIC_INTERPOSITION)
endif()
endif()
diff --git a/llvm/include/llvm/Analysis/LazyCallGraph.h b/llvm/include/llvm/Analysis/LazyCallGraph.h
index 81500905c0..148be34aa7 100644
--- a/llvm/include/llvm/Analysis/LazyCallGraph.h
+++ b/llvm/include/llvm/Analysis/LazyCallGraph.h
@@ -1098,28 +1098,10 @@ class LazyCallGraph {
continue;
}
- // The blockaddress constant expression is a weird special case, we can't
- // generically walk its operands the way we do for all other constants.
- if (BlockAddress *BA = dyn_cast(C)) {
- // If we've already visited the function referred to by the block
- // address, we don't need to revisit it.
- if (Visited.count(BA->getFunction()))
- continue;
-
- // If all of the blockaddress' users are instructions within the
- // referred to function, we don't need to insert a cycle.
- if (llvm::all_of(BA->users(), [&](User *U) {
- if (Instruction *I = dyn_cast(U))
- return I->getFunction() == BA->getFunction();
- return false;
- }))
- continue;
-
- // Otherwise we should go visit the referred to function.
- Visited.insert(BA->getFunction());
- Worklist.push_back(BA->getFunction());
+ // blockaddresses are weird and don't participate in the call graph anyway,
+ // skip them.
+ if (isa(C))
continue;
- }
for (Value *Op : C->operand_values())
if (Visited.insert(cast(Op)).second)
diff --git a/llvm/include/llvm/CodeGen/TargetInstrInfo.h b/llvm/include/llvm/CodeGen/TargetInstrInfo.h
index 05d0591f1e..35c3315391 100644
--- a/llvm/include/llvm/CodeGen/TargetInstrInfo.h
+++ b/llvm/include/llvm/CodeGen/TargetInstrInfo.h
@@ -1922,9 +1922,7 @@ class TargetInstrInfo : public MCInstrInfo {
/// Optional target hook that returns true if \p MBB is safe to outline from,
/// and returns any target-specific information in \p Flags.
virtual bool isMBBSafeToOutlineFrom(MachineBasicBlock &MBB,
- unsigned &Flags) const {
- return true;
- }
+ unsigned &Flags) const;
/// Insert a custom frame for outlined functions.
virtual void buildOutlinedFrame(MachineBasicBlock &MBB, MachineFunction &MF,
diff --git a/llvm/include/llvm/IR/Metadata.h b/llvm/include/llvm/IR/Metadata.h
index c584056445..17a9c3a77f 100644
--- a/llvm/include/llvm/IR/Metadata.h
+++ b/llvm/include/llvm/IR/Metadata.h
@@ -897,6 +897,7 @@ struct TempMDNodeDeleter {
class MDNode : public Metadata {
friend class ReplaceableMetadataImpl;
friend class LLVMContextImpl;
+ friend class DIArgList;
unsigned NumOperands;
unsigned NumUnresolved;
diff --git a/llvm/lib/Analysis/AliasAnalysis.cpp b/llvm/lib/Analysis/AliasAnalysis.cpp
index e7445e225d..1da712eb9d 100644
--- a/llvm/lib/Analysis/AliasAnalysis.cpp
+++ b/llvm/lib/Analysis/AliasAnalysis.cpp
@@ -697,14 +697,16 @@ ModRefInfo AAResults::getModRefInfo(const Instruction *I,
case Instruction::AtomicRMW:
return getModRefInfo((const AtomicRMWInst *)I, Loc, AAQIP);
case Instruction::Call:
- return getModRefInfo((const CallInst *)I, Loc, AAQIP);
+ case Instruction::CallBr:
case Instruction::Invoke:
- return getModRefInfo((const InvokeInst *)I, Loc, AAQIP);
+ return getModRefInfo((const CallBase *)I, Loc, AAQIP);
case Instruction::CatchPad:
return getModRefInfo((const CatchPadInst *)I, Loc, AAQIP);
case Instruction::CatchRet:
return getModRefInfo((const CatchReturnInst *)I, Loc, AAQIP);
default:
+ assert(!I->mayReadOrWriteMemory() &&
+ "Unhandled memory access instruction!");
return ModRefInfo::NoModRef;
}
}
diff --git a/llvm/lib/Analysis/InlineCost.cpp b/llvm/lib/Analysis/InlineCost.cpp
index 4c2413e144..e8f79a28a8 100644
--- a/llvm/lib/Analysis/InlineCost.cpp
+++ b/llvm/lib/Analysis/InlineCost.cpp
@@ -354,6 +354,7 @@ class CallAnalyzer : public InstVisitor {
bool simplifyCallSite(Function *F, CallBase &Call);
template
bool simplifyInstruction(Instruction &I, Callable Evaluate);
+ bool simplifyIntrinsicCallIsConstant(CallBase &CB);
ConstantInt *stripAndComputeInBoundsConstantOffsets(Value *&V);
/// Return true if the given argument to the function being considered for
@@ -1471,6 +1472,27 @@ bool CallAnalyzer::simplifyInstruction(Instruction &I, Callable Evaluate) {
return true;
}
+/// Try to simplify a call to llvm.is.constant.
+///
+/// Duplicate the argument checking from CallAnalyzer::simplifyCallSite since
+/// we expect calls of this specific intrinsic to be infrequent.
+///
+/// FIXME: Given that we know CB's parent (F) caller
+/// (CandidateCall->getParent()->getParent()), we might be able to determine
+/// whether inlining F into F's caller would change how the call to
+/// llvm.is.constant would evaluate.
+bool CallAnalyzer::simplifyIntrinsicCallIsConstant(CallBase &CB) {
+ Value *Arg = CB.getArgOperand(0);
+ auto *C = dyn_cast(Arg);
+
+ if (!C)
+ C = dyn_cast_or_null(SimplifiedValues.lookup(Arg));
+
+ Type *RT = CB.getFunctionType()->getReturnType();
+ SimplifiedValues[&CB] = ConstantInt::get(RT, C ? 1 : 0);
+ return true;
+}
+
bool CallAnalyzer::visitBitCast(BitCastInst &I) {
// Propagate constants through bitcasts.
if (simplifyInstruction(I, [&](SmallVectorImpl &COps) {
@@ -2091,6 +2113,8 @@ bool CallAnalyzer::visitCallBase(CallBase &Call) {
if (auto *SROAArg = getSROAArgForValueOrNull(II->getOperand(0)))
SROAArgValues[II] = SROAArg;
return true;
+ case Intrinsic::is_constant:
+ return simplifyIntrinsicCallIsConstant(Call);
}
}
diff --git a/llvm/lib/CodeGen/RegAllocFast.cpp b/llvm/lib/CodeGen/RegAllocFast.cpp
index 707161d5a8..68920e2e50 100644
--- a/llvm/lib/CodeGen/RegAllocFast.cpp
+++ b/llvm/lib/CodeGen/RegAllocFast.cpp
@@ -15,6 +15,7 @@
#include "llvm/ADT/ArrayRef.h"
#include "llvm/ADT/DenseMap.h"
#include "llvm/ADT/IndexedMap.h"
+#include "llvm/ADT/MapVector.h"
#include "llvm/ADT/SmallSet.h"
#include "llvm/ADT/SmallVector.h"
#include "llvm/ADT/SparseSet.h"
@@ -432,7 +433,7 @@ void RegAllocFast::spill(MachineBasicBlock::iterator Before, Register VirtReg,
// every definition of it, meaning we can switch all the DBG_VALUEs over
// to just reference the stack slot.
SmallVectorImpl &LRIDbgOperands = LiveDbgValueMap[VirtReg];
- SmallDenseMap>
+ SmallMapVector, 2>
SpilledOperandsMap;
for (MachineOperand *MO : LRIDbgOperands)
SpilledOperandsMap[MO->getParent()].push_back(MO);
diff --git a/llvm/lib/CodeGen/TargetInstrInfo.cpp b/llvm/lib/CodeGen/TargetInstrInfo.cpp
index 2e4a656ea0..4bbb5beb21 100644
--- a/llvm/lib/CodeGen/TargetInstrInfo.cpp
+++ b/llvm/lib/CodeGen/TargetInstrInfo.cpp
@@ -1417,3 +1417,16 @@ std::string TargetInstrInfo::createMIROperandComment(
}
TargetInstrInfo::PipelinerLoopInfo::~PipelinerLoopInfo() {}
+
+bool TargetInstrInfo::isMBBSafeToOutlineFrom(MachineBasicBlock &MBB,
+ unsigned &Flags) const {
+ // Some instrumentations create special TargetOpcode at the start which
+ // expands to special code sequences which must be present.
+ auto First = MBB.getFirstNonDebugInstr();
+ if (First != MBB.end() &&
+ (First->getOpcode() == TargetOpcode::FENTRY_CALL ||
+ First->getOpcode() == TargetOpcode::PATCHABLE_FUNCTION_ENTER))
+ return false;
+
+ return true;
+}
diff --git a/llvm/lib/IR/DebugInfoMetadata.cpp b/llvm/lib/IR/DebugInfoMetadata.cpp
index 7b0dab799e..2180eedb58 100644
--- a/llvm/lib/IR/DebugInfoMetadata.cpp
+++ b/llvm/lib/IR/DebugInfoMetadata.cpp
@@ -1592,6 +1592,12 @@ void DIArgList::handleChangedOperand(void *Ref, Metadata *New) {
assert((!New || isa(New)) &&
"DIArgList must be passed a ValueAsMetadata");
untrack();
+ bool Uniq = isUniqued();
+ if (Uniq) {
+ // We need to update the uniqueness once the Args are updated since they
+ // form the key to the DIArgLists store.
+ eraseFromStore();
+ }
ValueAsMetadata *NewVM = cast_or_null(New);
for (ValueAsMetadata *&VM : Args) {
if (&VM == OldVMPtr) {
@@ -1601,6 +1607,10 @@ void DIArgList::handleChangedOperand(void *Ref, Metadata *New) {
VM = ValueAsMetadata::get(UndefValue::get(VM->getValue()->getType()));
}
}
+ if (Uniq) {
+ if (uniquify() != this)
+ storeDistinctInContext();
+ }
track();
}
void DIArgList::track() {
diff --git a/llvm/lib/IR/LLVMContextImpl.cpp b/llvm/lib/IR/LLVMContextImpl.cpp
index 99819602c5..85ac63eaa1 100644
--- a/llvm/lib/IR/LLVMContextImpl.cpp
+++ b/llvm/lib/IR/LLVMContextImpl.cpp
@@ -55,8 +55,15 @@ LLVMContextImpl::~LLVMContextImpl() {
// Drop references for MDNodes. Do this before Values get deleted to avoid
// unnecessary RAUW when nodes are still unresolved.
- for (auto *I : DistinctMDNodes)
+ for (auto *I : DistinctMDNodes) {
+ // We may have DIArgList that were uniqued, and as it has a custom
+ // implementation of dropAllReferences, it needs to be explicitly invoked.
+ if (auto *AL = dyn_cast(I)) {
+ AL->dropAllReferences();
+ continue;
+ }
I->dropAllReferences();
+ }
#define HANDLE_MDNODE_LEAF_UNIQUABLE(CLASS) \
for (auto *I : CLASS##s) \
I->dropAllReferences();
diff --git a/llvm/lib/IR/LLVMContextImpl.h b/llvm/lib/IR/LLVMContextImpl.h
index 2ae23fdc95..655319eb1c 100644
--- a/llvm/lib/IR/LLVMContextImpl.h
+++ b/llvm/lib/IR/LLVMContextImpl.h
@@ -391,8 +391,9 @@ template <> struct MDNodeKeyImpl {
IsUnsigned(N->isUnsigned()) {}
bool isKeyOf(const DIEnumerator *RHS) const {
- return APInt::isSameValue(Value, RHS->getValue()) &&
- IsUnsigned == RHS->isUnsigned() && Name == RHS->getRawName();
+ return Value.getBitWidth() == RHS->getValue().getBitWidth() &&
+ Value == RHS->getValue() && IsUnsigned == RHS->isUnsigned() &&
+ Name == RHS->getRawName();
}
unsigned getHashValue() const { return hash_combine(Value, Name); }
diff --git a/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp b/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
index 091a62aa4a..f29bb83c2d 100644
--- a/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
+++ b/llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
@@ -6923,6 +6923,8 @@ bool AArch64InstrInfo::isFunctionSafeToOutlineFrom(
bool AArch64InstrInfo::isMBBSafeToOutlineFrom(MachineBasicBlock &MBB,
unsigned &Flags) const {
+ if (!TargetInstrInfo::isMBBSafeToOutlineFrom(MBB, Flags))
+ return false;
// Check if LR is available through all of the MBB. If it's not, then set
// a flag.
assert(MBB.getParent()->getRegInfo().tracksLiveness() &&
diff --git a/llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp b/llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp
index 8c34027f7b..94a0ce09af 100644
--- a/llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp
+++ b/llvm/lib/Target/AArch64/GISel/AArch64RegisterBankInfo.cpp
@@ -13,6 +13,8 @@
#include "AArch64RegisterBankInfo.h"
#include "AArch64InstrInfo.h"
+#include "AArch64RegisterInfo.h"
+#include "MCTargetDesc/AArch64MCTargetDesc.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/ADT/SmallVector.h"
#include "llvm/CodeGen/GlobalISel/RegisterBank.h"
@@ -271,6 +273,7 @@ AArch64RegisterBankInfo::getRegBankFromRegClass(const TargetRegisterClass &RC,
case AArch64::WSeqPairsClassRegClassID:
case AArch64::XSeqPairsClassRegClassID:
case AArch64::MatrixIndexGPR32_12_15RegClassID:
+ case AArch64::GPR64_with_sub_32_in_MatrixIndexGPR32_12_15RegClassID:
return getRegBank(AArch64::GPRRegBankID);
case AArch64::CCRRegClassID:
return getRegBank(AArch64::CCRegBankID);
diff --git a/llvm/lib/Target/ARM/ARMCallLowering.cpp b/llvm/lib/Target/ARM/ARMCallLowering.cpp
index aff7ec8d2e..256a95b94f 100644
--- a/llvm/lib/Target/ARM/ARMCallLowering.cpp
+++ b/llvm/lib/Target/ARM/ARMCallLowering.cpp
@@ -525,7 +525,7 @@ bool ARMCallLowering::lowerCall(MachineIRBuilder &MIRBuilder, CallLoweringInfo &
MIRBuilder.buildInstr(ARM::ADJCALLSTACKUP)
.addImm(ArgAssigner.StackOffset)
- .addImm(0)
+ .addImm(-1ULL)
.add(predOps(ARMCC::AL));
return true;
diff --git a/llvm/lib/Target/ARM/ARMFastISel.cpp b/llvm/lib/Target/ARM/ARMFastISel.cpp
index 28a076edd6..9224c2221f 100644
--- a/llvm/lib/Target/ARM/ARMFastISel.cpp
+++ b/llvm/lib/Target/ARM/ARMFastISel.cpp
@@ -2022,7 +2022,7 @@ bool ARMFastISel::FinishCall(MVT RetVT, SmallVectorImpl &UsedRegs,
unsigned AdjStackUp = TII.getCallFrameDestroyOpcode();
AddOptionalDefs(BuildMI(*FuncInfo.MBB, FuncInfo.InsertPt, DbgLoc,
TII.get(AdjStackUp))
- .addImm(NumBytes).addImm(0));
+ .addImm(NumBytes).addImm(-1ULL));
// Now the return value.
if (RetVT != MVT::isVoid) {
diff --git a/llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp b/llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp
index 9c7055deaa..7c238a1099 100644
--- a/llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp
+++ b/llvm/lib/Target/ARM/ARMISelDAGToDAG.cpp
@@ -79,6 +79,10 @@ class ARMDAGToDAGISel : public SelectionDAGISel {
void Select(SDNode *N) override;
+ /// Return true as some complex patterns, like those that call
+ /// canExtractShiftFromMul can modify the DAG inplace.
+ bool ComplexPatternFuncMutatesDAG() const override { return true; }
+
bool hasNoVMLxHazardUse(SDNode *N) const;
bool isShifterOpProfitable(const SDValue &Shift,
ARM_AM::ShiftOpc ShOpcVal, unsigned ShAmt);
diff --git a/llvm/lib/Target/RISCV/RISCVInstrInfo.cpp b/llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
index 207101763a..7dab7a52ac 100644
--- a/llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
+++ b/llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
@@ -999,7 +999,7 @@ bool RISCVInstrInfo::isFunctionSafeToOutlineFrom(
bool RISCVInstrInfo::isMBBSafeToOutlineFrom(MachineBasicBlock &MBB,
unsigned &Flags) const {
// More accurate safety checking is done in getOutliningCandidateInfo.
- return true;
+ return TargetInstrInfo::isMBBSafeToOutlineFrom(MBB, Flags);
}
// Enum values indicating how an outlined call should be constructed.
diff --git a/llvm/lib/Target/X86/X86ISelLowering.cpp b/llvm/lib/Target/X86/X86ISelLowering.cpp
index f3b1e6ca70..4b13b5b540 100644
--- a/llvm/lib/Target/X86/X86ISelLowering.cpp
+++ b/llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -44076,32 +44076,9 @@ static SDValue combineVectorHADDSUB(SDNode *N, SelectionDAG &DAG,
"Unexpected horizontal add/sub opcode");
if (!shouldUseHorizontalOp(true, DAG, Subtarget)) {
- // For slow-hop targets, if we have a hop with a single op, see if we already
- // have another user that we can reuse and shuffle the result.
MVT VT = N->getSimpleValueType(0);
SDValue LHS = N->getOperand(0);
SDValue RHS = N->getOperand(1);
- if (VT.is128BitVector() && LHS == RHS) {
- for (SDNode *User : LHS->uses()) {
- if (User != N && User->getOpcode() == N->getOpcode()) {
- MVT ShufVT = VT.isFloatingPoint() ? MVT::v4f32 : MVT::v4i32;
- if (User->getOperand(0) == LHS && !User->getOperand(1).isUndef()) {
- return DAG.getBitcast(
- VT,
- DAG.getVectorShuffle(ShufVT, SDLoc(N),
- DAG.getBitcast(ShufVT, SDValue(User, 0)),
- DAG.getUNDEF(ShufVT), {0, 1, 0, 1}));
- }
- if (User->getOperand(1) == LHS && !User->getOperand(0).isUndef()) {
- return DAG.getBitcast(
- VT,
- DAG.getVectorShuffle(ShufVT, SDLoc(N),
- DAG.getBitcast(ShufVT, SDValue(User, 0)),
- DAG.getUNDEF(ShufVT), {2, 3, 2, 3}));
- }
- }
- }
- }
// HOP(HOP'(X,X),HOP'(Y,Y)) -> HOP(PERMUTE(HOP'(X,Y)),PERMUTE(HOP'(X,Y)).
if (LHS != RHS && LHS.getOpcode() == N->getOpcode() &&
diff --git a/llvm/lib/Target/X86/X86InstrSystem.td b/llvm/lib/Target/X86/X86InstrSystem.td
index 48c27051a8..355ddf26e3 100644
--- a/llvm/lib/Target/X86/X86InstrSystem.td
+++ b/llvm/lib/Target/X86/X86InstrSystem.td
@@ -583,7 +583,7 @@ def XRSTORS64 : RI<0xC7, MRM3m, (outs), (ins opaquemem:$dst),
//===----------------------------------------------------------------------===//
// VIA PadLock crypto instructions
let Defs = [RAX, RDI], Uses = [RDX, RDI], SchedRW = [WriteSystem] in
- def XSTORE : I<0xa7, MRM_C0, (outs), (ins), "xstore", []>, TB, REP;
+ def XSTORE : I<0xa7, MRM_C0, (outs), (ins), "xstore", []>, TB;
def : InstAlias<"xstorerng", (XSTORE)>;
diff --git a/llvm/lib/Transforms/Coroutines/CoroSplit.cpp b/llvm/lib/Transforms/Coroutines/CoroSplit.cpp
index b6932dbbfc..fc83befe39 100644
--- a/llvm/lib/Transforms/Coroutines/CoroSplit.cpp
+++ b/llvm/lib/Transforms/Coroutines/CoroSplit.cpp
@@ -29,6 +29,7 @@
#include "llvm/Analysis/CFG.h"
#include "llvm/Analysis/CallGraph.h"
#include "llvm/Analysis/CallGraphSCCPass.h"
+#include "llvm/Analysis/ConstantFolding.h"
#include "llvm/Analysis/LazyCallGraph.h"
#include "llvm/IR/Argument.h"
#include "llvm/IR/Attributes.h"
@@ -1174,6 +1175,15 @@ scanPHIsAndUpdateValueMap(Instruction *Prev, BasicBlock *NewBlock,
static bool simplifyTerminatorLeadingToRet(Instruction *InitialInst) {
DenseMap ResolvedValues;
BasicBlock *UnconditionalSucc = nullptr;
+ assert(InitialInst->getModule());
+ const DataLayout &DL = InitialInst->getModule()->getDataLayout();
+
+ auto TryResolveConstant = [&ResolvedValues](Value *V) {
+ auto It = ResolvedValues.find(V);
+ if (It != ResolvedValues.end())
+ V = It->second;
+ return dyn_cast(V);
+ };
Instruction *I = InitialInst;
while (I->isTerminator() ||
@@ -1190,47 +1200,65 @@ static bool simplifyTerminatorLeadingToRet(Instruction *InitialInst) {
}
if (auto *BR = dyn_cast(I)) {
if (BR->isUnconditional()) {
- BasicBlock *BB = BR->getSuccessor(0);
+ BasicBlock *Succ = BR->getSuccessor(0);
if (I == InitialInst)
- UnconditionalSucc = BB;
- scanPHIsAndUpdateValueMap(I, BB, ResolvedValues);
- I = BB->getFirstNonPHIOrDbgOrLifetime();
+ UnconditionalSucc = Succ;
+ scanPHIsAndUpdateValueMap(I, Succ, ResolvedValues);
+ I = Succ->getFirstNonPHIOrDbgOrLifetime();
+ continue;
+ }
+
+ BasicBlock *BB = BR->getParent();
+ // Handle the case the condition of the conditional branch is constant.
+ // e.g.,
+ //
+ // br i1 false, label %cleanup, label %CoroEnd
+ //
+ // It is possible during the transformation. We could continue the
+ // simplifying in this case.
+ if (ConstantFoldTerminator(BB, /*DeleteDeadConditions=*/true)) {
+ // Handle this branch in next iteration.
+ I = BB->getTerminator();
continue;
}
} else if (auto *CondCmp = dyn_cast(I)) {
+ // If the case number of suspended switch instruction is reduced to
+ // 1, then it is simplified to CmpInst in llvm::ConstantFoldTerminator.
auto *BR = dyn_cast(I->getNextNode());
- if (BR && BR->isConditional() && CondCmp == BR->getCondition()) {
- // If the case number of suspended switch instruction is reduced to
- // 1, then it is simplified to CmpInst in llvm::ConstantFoldTerminator.
- // And the comparsion looks like : %cond = icmp eq i8 %V, constant.
- ConstantInt *CondConst = dyn_cast(CondCmp->getOperand(1));
- if (CondConst && CondCmp->getPredicate() == CmpInst::ICMP_EQ) {
- Value *V = CondCmp->getOperand(0);
- auto it = ResolvedValues.find(V);
- if (it != ResolvedValues.end())
- V = it->second;
-
- if (ConstantInt *Cond0 = dyn_cast(V)) {
- BasicBlock *BB = Cond0->equalsInt(CondConst->getZExtValue())
- ? BR->getSuccessor(0)
- : BR->getSuccessor(1);
- scanPHIsAndUpdateValueMap(I, BB, ResolvedValues);
- I = BB->getFirstNonPHIOrDbgOrLifetime();
- continue;
- }
- }
- }
+ if (!BR || !BR->isConditional() || CondCmp != BR->getCondition())
+ return false;
+
+ // And the comparsion looks like : %cond = icmp eq i8 %V, constant.
+ // So we try to resolve constant for the first operand only since the
+ // second operand should be literal constant by design.
+ ConstantInt *Cond0 = TryResolveConstant(CondCmp->getOperand(0));
+ auto *Cond1 = dyn_cast(CondCmp->getOperand(1));
+ if (!Cond0 || !Cond1)
+ return false;
+
+ // Both operands of the CmpInst are Constant. So that we could evaluate
+ // it immediately to get the destination.
+ auto *ConstResult =
+ dyn_cast_or_null(ConstantFoldCompareInstOperands(
+ CondCmp->getPredicate(), Cond0, Cond1, DL));
+ if (!ConstResult)
+ return false;
+
+ CondCmp->replaceAllUsesWith(ConstResult);
+ CondCmp->eraseFromParent();
+
+ // Handle this branch in next iteration.
+ I = BR;
+ continue;
} else if (auto *SI = dyn_cast(I)) {
- Value *V = SI->getCondition();
- auto it = ResolvedValues.find(V);
- if (it != ResolvedValues.end())
- V = it->second;
- if (ConstantInt *Cond = dyn_cast(V)) {
- BasicBlock *BB = SI->findCaseValue(Cond)->getCaseSuccessor();
- scanPHIsAndUpdateValueMap(I, BB, ResolvedValues);
- I = BB->getFirstNonPHIOrDbgOrLifetime();
- continue;
- }
+ ConstantInt *Cond = TryResolveConstant(SI->getCondition());
+ if (!Cond)
+ return false;
+
+ BasicBlock *BB = SI->findCaseValue(Cond)->getCaseSuccessor();
+ scanPHIsAndUpdateValueMap(I, BB, ResolvedValues);
+ I = BB->getFirstNonPHIOrDbgOrLifetime();
+ continue;
}
return false;
}
diff --git a/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp b/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
index 4e3b18e805..71b3a411cc 100644
--- a/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
+++ b/llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
@@ -2843,6 +2843,26 @@ static Instruction *tryToMoveFreeBeforeNullTest(CallInst &FI,
}
assert(FreeInstrBB->size() == 1 &&
"Only the branch instruction should remain");
+
+ // Now that we've moved the call to free before the NULL check, we have to
+ // remove any attributes on its parameter that imply it's non-null, because
+ // those attributes might have only been valid because of the NULL check, and
+ // we can get miscompiles if we keep them. This is conservative if non-null is
+ // also implied by something other than the NULL check, but it's guaranteed to
+ // be correct, and the conservativeness won't matter in practice, since the
+ // attributes are irrelevant for the call to free itself and the pointer
+ // shouldn't be used after the call.
+ AttributeList Attrs = FI.getAttributes();
+ Attrs = Attrs.removeParamAttribute(FI.getContext(), 0, Attribute::NonNull);
+ Attribute Dereferenceable = Attrs.getParamAttr(0, Attribute::Dereferenceable);
+ if (Dereferenceable.isValid()) {
+ uint64_t Bytes = Dereferenceable.getDereferenceableBytes();
+ Attrs = Attrs.removeParamAttribute(FI.getContext(), 0,
+ Attribute::Dereferenceable);
+ Attrs = Attrs.addDereferenceableOrNullParamAttr(FI.getContext(), 0, Bytes);
+ }
+ FI.setAttributes(Attrs);
+
return &FI;
}
diff --git a/llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp b/llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp
index d22b3f4095..9d8130d1ac 100644
--- a/llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp
+++ b/llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp
@@ -1303,17 +1303,10 @@ struct DSEState {
/// loop. In particular, this guarantees that it only references a single
/// MemoryLocation during execution of the containing function.
bool isGuaranteedLoopInvariant(const Value *Ptr) {
- auto IsGuaranteedLoopInvariantBase = [this](const Value *Ptr) {
+ auto IsGuaranteedLoopInvariantBase = [](const Value *Ptr) {
Ptr = Ptr->stripPointerCasts();
- if (auto *I = dyn_cast(Ptr)) {
- if (isa(Ptr))
- return true;
-
- if (isAllocLikeFn(I, &TLI))
- return true;
-
- return false;
- }
+ if (auto *I = dyn_cast(Ptr))
+ return I->getParent()->isEntryBlock();
return true;
};
diff --git a/llvm/unittests/Analysis/LazyCallGraphTest.cpp b/llvm/unittests/Analysis/LazyCallGraphTest.cpp
index b154c6f290..d6e73f3a95 100644
--- a/llvm/unittests/Analysis/LazyCallGraphTest.cpp
+++ b/llvm/unittests/Analysis/LazyCallGraphTest.cpp
@@ -1978,7 +1978,8 @@ TEST(LazyCallGraphTest, HandleBlockAddress) {
LazyCallGraph::Node &G = *CG.lookup(lookupFunction(*M, "g"));
EXPECT_EQ(&FRC, CG.lookupRefSCC(F));
EXPECT_EQ(&GRC, CG.lookupRefSCC(G));
- EXPECT_TRUE(GRC.isParentOf(FRC));
+ EXPECT_FALSE(GRC.isParentOf(FRC));
+ EXPECT_FALSE(FRC.isParentOf(GRC));
}
// Test that a blockaddress that refers to itself creates no new RefSCC
diff --git a/llvm/unittests/IR/DebugInfoTest.cpp b/llvm/unittests/IR/DebugInfoTest.cpp
index 060a5c2b08..17b6e54644 100644
--- a/llvm/unittests/IR/DebugInfoTest.cpp
+++ b/llvm/unittests/IR/DebugInfoTest.cpp
@@ -7,8 +7,9 @@
//===----------------------------------------------------------------------===//
#include "llvm/IR/DebugInfo.h"
-#include "llvm/IR/DIBuilder.h"
+#include "llvm/ADT/APSInt.h"
#include "llvm/AsmParser/Parser.h"
+#include "llvm/IR/DIBuilder.h"
#include "llvm/IR/DebugInfoMetadata.h"
#include "llvm/IR/IntrinsicInst.h"
#include "llvm/IR/LLVMContext.h"
@@ -244,4 +245,21 @@ TEST(DIBuilder, CreateSetType) {
EXPECT_TRUE(isa_and_nonnull(SetType));
}
+TEST(DIBuilder, DIEnumerator) {
+ LLVMContext Ctx;
+ std::unique_ptr M(new Module("MyModule", Ctx));
+ DIBuilder DIB(*M);
+ APSInt I1(APInt(32, 1));
+ APSInt I2(APInt(33, 1));
+
+ auto *E = DIEnumerator::get(Ctx, I1, I1.isSigned(), "name");
+ EXPECT_TRUE(E);
+
+ auto *E1 = DIEnumerator::getIfExists(Ctx, I1, I1.isSigned(), "name");
+ EXPECT_TRUE(E1);
+
+ auto *E2 = DIEnumerator::getIfExists(Ctx, I2, I1.isSigned(), "name");
+ EXPECT_FALSE(E2);
+}
+
} // end namespace
diff --git a/zig/CMakeLists.txt b/zig/CMakeLists.txt
index 39e56ea961..638f39f7e5 100644
--- a/zig/CMakeLists.txt
+++ b/zig/CMakeLists.txt
@@ -26,7 +26,7 @@ set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake ${CMAKE_MODULE_PATH})
set(ZIG_VERSION_MAJOR 0)
set(ZIG_VERSION_MINOR 9)
-set(ZIG_VERSION_PATCH 0)
+set(ZIG_VERSION_PATCH 1)
set(ZIG_VERSION "" CACHE STRING "Override Zig version string. Default is to find out with git.")
if("${ZIG_VERSION}" STREQUAL "")
@@ -787,7 +787,7 @@ else()
set(ZIG1_RELEASE_ARG -OReleaseFast --strip)
endif()
if(ZIG_SINGLE_THREADED)
- set(ZIG1_SINGLE_THREADED_ARG "--single-threaded")
+ set(ZIG1_SINGLE_THREADED_ARG "-fsingle-threaded")
else()
set(ZIG1_SINGLE_THREADED_ARG "")
endif()
diff --git a/zig/CODE_OF_CONDUCT.md b/zig/CODE_OF_CONDUCT.md
deleted file mode 100644
index fdde187d01..0000000000
--- a/zig/CODE_OF_CONDUCT.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# Code of Conduct
-
-Hello, and welcome! 👋
-
-The Zig community is decentralized. Anyone is free to start and maintain their
-own space for people to gather, and edit
-[the Community wiki page](https://github.com/ziglang/zig/wiki/Community) to add
-a link. There is no concept of "official" or "unofficial", however, each
-gathering place has its own moderators and rules.
-
-This is Andrew Kelley speaking. At least for now, I'm the moderator of the
-ziglang organization GitHub repositories and the #zig IRC channel on Libera.chat.
-**This document contains the rules that govern these two spaces only**.
-
-The rules here are strict. This space is for focused, on topic, technical work
-on the Zig project only. It is everyone's responsibility to maintain a positive
-environment, especially when disagreements occur.
-
-## Our Standards
-
-Examples of behavior that contribute to creating a positive environment include:
-
- * Using welcoming and inclusive language.
- * Being respectful of differing viewpoints and experiences.
- * Gracefully accepting constructive criticism.
- * Helping another person accomplish their own goals.
- * Showing empathy towards others.
- * Showing appreciation for others' work.
- * Validating someone else's experience, skills, insight, and use cases.
-
-Examples of unacceptable behavior by participants include:
-
- * Unwelcome sexual attention or advances, or use of sexualized language or
- imagery that causes discomfort.
- * Trolling, insulting/derogatory comments, and personal attacks. Anything
- antagonistic towards someone else.
- * Off-topic discussion of any kind - especially offensive or sensitive issues.
- * Publishing others' private information, such as a physical or electronic
- address, without explicit permission.
- * Discussing this Code of Conduct or publicly accusing someone of violating it.
- * Making someone else feel like an outsider or implying a lack of technical
- abilities.
- * Destructive behavior. Anything that harms Zig or another open-source project.
-
-## Enforcement
-
-If you need to report an issue you can contact me or Loris Cro, who are both
-paid by the Zig Software Foundation, and so moderation of this space is part of
-our job. We will swiftly remove anyone who is antagonizing others or being
-generally destructive.
-
-This includes Private Harassment. If person A is directly harassed or
-antagonized by person B, person B will be blocked from participating in this
-space even if the harassment didn't take place on one of the mediums directly
-under rule of this Code of Conduct.
-
-As noted, discussing this Code of Conduct should not take place on GitHub or IRC
-because these spaces are for directly working on code, not for meta-discussion.
-If you have any issues with it, you can contact me directly, or you can join one
-of the community spaces that has different rules.
-
- * Andrew Kelley
- * Loris Cro
-
-## Conclusion
-
-Thanks for reading the rules. Together, we can make this space welcoming and
-inclusive for everyone, regardless of age, body size, disability, ethnicity,
-sex characteristics, gender identity and expression, level of experience,
-education, socio-economic status, nationality, personal appearance, race,
-religion, or sexual identity and orientation.
-
-Sincerely,
-
-Andrew ✌️
diff --git a/zig/CONTRIBUTING.md b/zig/CONTRIBUTING.md
deleted file mode 100644
index acaa2f1b6c..0000000000
--- a/zig/CONTRIBUTING.md
+++ /dev/null
@@ -1,213 +0,0 @@
-## Contributing
-
-### Start a Project Using Zig
-
-One of the best ways you can contribute to Zig is to start using it for a
-personal project. Here are some great examples:
-
- * [Oxid](https://github.com/dbandstra/oxid) - arcade style game
- * [TM35-Metronome](https://github.com/TM35-Metronome) - tools for modifying and randomizing Pokémon games
- * [River](https://github.com/ifreund/river/) - a dynamic tiling wayland compositor
-
-More examples can be found on the
-[Community Projects Wiki](https://github.com/ziglang/zig/wiki/Community-Projects).
-
-Without fail, these projects lead to discovering bugs and helping flesh out use
-cases, which lead to further design iterations of Zig. Importantly, each issue
-found this way comes with real world motivations, so it is easy to explain
-your reasoning behind proposals and feature requests.
-
-Ideally, such a project will help you to learn new skills and add something
-to your personal portfolio at the same time.
-
-### Spread the Word
-
-Another way to contribute is to write about Zig, or speak about Zig at a
-conference, or do either of those things for your project which uses Zig.
-Here are some examples:
-
- * [Iterative Replacement of C with Zig](http://tiehuis.github.io/blog/zig1.html)
- * [The Right Tool for the Right Job: Redis Modules & Zig](https://www.youtube.com/watch?v=eCHM8-_poZY)
- * [Writing a small ray tracer in Rust and Zig](https://nelari.us/post/raytracer_with_rust_and_zig/)
-
-Zig is a brand new language, with no advertising budget. Word of mouth is the
-only way people find out about the project, and the more people hear about it,
-the more people will use it, and the better chance we have to take over the
-world.
-
-### Finding Contributor Friendly Issues
-
-Please note that issues labeled
-[Proposal](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+label%3Aproposal)
-but do not also have the
-[Accepted](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+label%3Aaccepted)
-label are still under consideration, and efforts to implement such a proposal
-have a high risk of being wasted. If you are interested in a proposal which is
-still under consideration, please express your interest in the issue tracker,
-providing extra insights and considerations that others have not yet expressed.
-The most highly regarded argument in such a discussion is a real world use case.
-
-The issue label
-[Contributor Friendly](https://github.com/ziglang/zig/issues?q=is%3Aissue+is%3Aopen+label%3A%22contributor+friendly%22)
-exists to help you find issues that are **limited in scope and/or
-knowledge of Zig internals.**
-
-### Editing Source Code
-
-First, build the Stage 1 compiler as described in
-[Building Zig From Source](https://github.com/ziglang/zig/wiki/Building-Zig-From-Source).
-
-Zig locates lib files relative to executable path by searching up the
-filesystem tree for a sub-path of `lib/zig/std/std.zig` or `lib/std/std.zig`.
-Typically the former is an install and the latter a git working tree which
-contains the build directory.
-
-During development it is not necessary to perform installs when modifying
-stage1 or userland sources and in fact it is faster and simpler to run,
-test and debug from a git working tree.
-
-- `make` is typically sufficient to build zig during development iterations.
-- `make install` performs a build __and__ install.
-- `msbuild -p:Configuration=Release INSTALL.vcxproj` on Windows performs a
-build and install. To avoid install, pass cmake option `-DZIG_SKIP_INSTALL_LIB_FILES=ON`.
-
-To test changes, do the following from the build directory:
-
-1. Run `make` (on POSIX) or
- `msbuild -p:Configuration=Release INSTALL.vcxproj` (on Windows).
-2. `$BUILD_DIR/zig build test` (on POSIX) or
- `$BUILD_DIR/Release\zig.exe build test` (on Windows).
-
-That runs the whole test suite, which does a lot of extra testing that you
-likely won't always need, and can take upwards of 1 hour. This is what the
-CI server runs when you make a pull request. (Note: actually it runs a few
-more tests; keep reading.)
-
-To save time, you can add the `--help` option to the `zig build` command and
-see what options are available. One of the most helpful ones is
-`-Dskip-release`. Adding this option to the command in step 2 above will take
-the time down from around 2 hours to about 6 minutes, and this is a good
-enough amount of testing before making a pull request.
-
-Another example is choosing a different set of things to test. For example,
-`test-std` instead of `test` will only run the standard library tests, and
-not the other ones. Combining this suggestion with the previous one, you could
-do this:
-
-`$BUILD_DIR/bin/zig build test-std -Dskip-release` (on POSIX) or
-`$BUILD_DIR/Release\zig.exe build test-std -Dskip-release` (on Windows).
-
-This will run only the standard library tests, in debug mode only, for all
-targets (it will cross-compile the tests for non-native targets but not run
-them).
-
-When making changes to the compiler source code, the most helpful test step to
-run is `test-behavior`. When editing documentation it is `docs`. You can find
-this information and more in the `--help` menu.
-
-#### Testing Changes to std lib
-
-To quickly test a change to a file in the standard library, you can run zig test and specify a custom lib directory with the follow command-line argument.
-
-```bash
-./build/zig test lib/std/fmt.zig --zig-lib-dir lib --main-pkg-path lib/std
-```
-
-#### Testing Non-Native Architectures with QEMU
-
-The Linux CI server additionally has qemu installed and sets `-fqemu`.
-This provides test coverage for, e.g. aarch64 even on x86_64 machines. It's
-recommended for Linux users to install qemu and enable this testing option
-when editing the standard library or anything related to a non-native
-architecture.
-
-##### glibc
-
-Testing foreign architectures with dynamically linked glibc is one step trickier.
-This requires enabling `--glibc-runtimes /path/to/glibc/multi/install/glibcs`.
-This path is obtained by building glibc for multiple architectures. This
-process for me took an entire day to complete and takes up 65 GiB on my hard
-drive. The CI server does not provide this test coverage. Instructions for
-producing this path can be found
-[on the wiki](https://github.com/ziglang/zig/wiki/Updating-libc#glibc).
-Just the part with `build-many-glibcs.py`.
-
-It's understood that most contributors will not have these tests enabled.
-
-#### Testing Windows from a Linux Machine with Wine
-
-When developing on Linux, another option is available to you: `-fwine`.
-This will enable running behavior tests and std lib tests with Wine. It's
-recommended for Linux users to install Wine and enable this testing option
-when editing the standard library or anything Windows-related.
-
-#### Testing WebAssembly using wasmtime
-
-If you have [wasmtime](https://wasmtime.dev/) installed, take advantage of the
-`-fwasmtime` flag which will enable running WASI behavior tests and std
-lib tests. It's recommended for all users to install wasmtime and enable this
-testing option when editing the standard library and especially anything
-WebAssembly-related.
-
-#### Improving Translate-C
-
-Please read the [Editing Source Code](#editing-source-code) section as a
-prerequisite to this one.
-
-`translate-c` is a feature provided by Zig that converts C source code into
-Zig source code. It powers the `zig translate-c` command as well as
-[@cImport](https://ziglang.org/documentation/master/#cImport), allowing Zig
-code to not only take advantage of function prototypes defined in .h files,
-but also `static inline` functions written in C, and even some macros.
-
-This feature works by using libclang API to parse and semantically analyze
-C/C++ files, and then based on the provided AST and type information,
-generating Zig AST, and finally using the mechanisms of `zig fmt` to render
-the Zig AST to a file.
-
-The relevant tests for this feature are:
-
- * `test/run_translated_c.zig` - each test case is C code with a `main` function. The C code
- is translated into Zig code, compiled, and run, and tests that the expected output is the
- same, and that the program exits cleanly. This kind of test coverage is preferred, when
- possible, because it makes sure that the resulting Zig code is actually viable.
-
- * `test/stage1/behavior/translate_c_macros.zig` - each test case consists of a Zig test
- which checks that the relevant macros in `test/stage1/behavior/translate_c_macros.h`.
- have the correct values. Macros have to be tested separately since they are expanded by
- Clang in `run_translated_c` tests.
-
- * `test/translate_c.zig` - each test case is C code, with a list of expected strings which
- must be found in the resulting Zig code. This kind of test is more precise in what it
- measures, but does not provide test coverage of whether the resulting Zig code is valid.
-
-This feature is self-hosted, even though Zig is not fully self-hosted yet. In the Zig source
-repo, we maintain a C API on top of Clang's C++ API:
-
- * `src/zig_clang.h` - the C API that we maintain on top of Clang's C++ API. This
- file does not include any Clang's C++ headers. Instead, C types and C enums are defined
- here.
-
- * `src/zig_clang.cpp` - a lightweight wrapper that fulfills the C API on top of the
- C++ API. It takes advantage of `static_assert` to make sure we get compile errors when
- Clang's C++ API changes. This one file necessarily does include Clang's C++ headers, which
- makes it the slowest-to-compile source file in all of Zig's codebase.
-
- * `src/clang.zig` - the Zig equivalent of `src/zig_clang.h`. This is a manually
- maintained list of types and functions that are ABI-compatible with the Clang C API we
- maintain. In theory this could be generated by running translate-c on `src/zig_clang.h`,
- but that would introduce a dependency cycle, since we are using this file to implement
- translate-c.
-
-Finally, the actual source code for the translate-c feature is
-`src/translate_c.zig`. This code uses the Clang C API exposed by
-`src/clang.zig`, and produces Zig AST.
-
-The steps for contributing to translate-c look like this:
-
- 1. Identify a test case you want to improve. Add it as a run-translated-c test
- case (usually preferable), or as a translate-c test case.
-
- 2. Edit `src/translate_c.zig` to improve the behavior.
-
- 3. Run the relevant tests: `./zig build test-run-translated-c test-translate-c`
diff --git a/zig/LICENSE b/zig/LICENSE
index 127e1ca7e3..6fda845a81 100644
--- a/zig/LICENSE
+++ b/zig/LICENSE
@@ -1,6 +1,6 @@
The MIT License (Expat)
-Copyright (c) 2015-2021, Zig contributors
+Copyright (c) 2015-2022, Zig contributors
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
diff --git a/zig/README.md b/zig/README.md
index e98eebf29f..cd8b4b4e96 100644
--- a/zig/README.md
+++ b/zig/README.md
@@ -1,4 +1,4 @@
-
+
A general-purpose programming language and toolchain for maintaining
**robust**, **optimal**, and **reusable** software.
diff --git a/zig/build.zig b/zig/build.zig
index 4e19d47c7f..d33e59dbf3 100644
--- a/zig/build.zig
+++ b/zig/build.zig
@@ -10,13 +10,13 @@ const fs = std.fs;
const InstallDirectoryOptions = std.build.InstallDirectoryOptions;
const assert = std.debug.assert;
-const zig_version = std.builtin.Version{ .major = 0, .minor = 9, .patch = 0 };
+const zig_version = std.builtin.Version{ .major = 0, .minor = 9, .patch = 1 };
pub fn build(b: *Builder) !void {
b.setPreferredReleaseMode(.ReleaseFast);
const mode = b.standardReleaseOptions();
const target = b.standardTargetOptions(.{});
- const single_threaded = b.option(bool, "single-threaded", "Build artifacts that run in single threaded mode") orelse false;
+ const single_threaded = b.option(bool, "single-threaded", "Build artifacts that run in single threaded mode");
const use_zig_libcxx = b.option(bool, "use-zig-libcxx", "If libc++ is needed, use zig's bundled version, don't try to integrate with the system") orelse false;
var docgen_exe = b.addExecutable("docgen", "doc/docgen.zig");
diff --git a/zig/cmake/Findlld.cmake b/zig/cmake/Findlld.cmake
index 5b5fbcb468..8a46888531 100644
--- a/zig/cmake/Findlld.cmake
+++ b/zig/cmake/Findlld.cmake
@@ -49,6 +49,7 @@ else()
FIND_AND_ADD_LLD_LIB(lldELF)
FIND_AND_ADD_LLD_LIB(lldCOFF)
FIND_AND_ADD_LLD_LIB(lldWasm)
+ FIND_AND_ADD_LLD_LIB(lldMachO)
FIND_AND_ADD_LLD_LIB(lldReaderWriter)
FIND_AND_ADD_LLD_LIB(lldCore)
FIND_AND_ADD_LLD_LIB(lldYAML)
diff --git a/zig/doc/langref.html.in b/zig/doc/langref.html.in
index 926b053ca0..c3541c62c0 100644
--- a/zig/doc/langref.html.in
+++ b/zig/doc/langref.html.in
@@ -1290,13 +1290,39 @@ test "expectError demo" {
A variable is a unit of {#link|Memory#} storage.
- Variables are never allowed to shadow identifiers from an outer scope.
-
-
It is generally preferable to use {#syntax#}const{#endsyntax#} rather than
{#syntax#}var{#endsyntax#} when declaring a variable. This causes less work for both
humans and computers to do when reading code, and creates more optimization opportunities.
+
+ {#header_open|Identifiers#}
+
+ Variable identifiers are never allowed to shadow identifiers from an outer scope.
+
+
+ Identifiers must start with an alphabetic character or underscore and may be followed
+ by any number of alphanumeric characters or underscores.
+ They must not overlap with any keywords. See {#link|Keyword Reference#}.
+
+
+ If a name that does not fit these requirements is needed, such as for linking with external libraries, the {#syntax#}@""{#endsyntax#} syntax may be used.
+
Container level variables have static lifetime and are order-independent and lazily analyzed.
@@ -1481,7 +1507,7 @@ fn divide(a: i32, b: i32) i32 {
Operators such as {#syntax#}+{#endsyntax#} and {#syntax#}-{#endsyntax#} cause undefined behavior on
- integer overflow. Alternative operators are provided for wrapping and saturating arithmetic on all targets.
+ integer overflow. Alternative operators are provided for wrapping and saturating arithmetic on all targets.
{#syntax#}+%{#endsyntax#} and {#syntax#}-%{#endsyntax#} perform wrapping arithmetic
while {#syntax#}+|{#endsyntax#} and {#syntax#}-|{#endsyntax#} perform saturating arithmetic.
@@ -2488,32 +2514,32 @@ test "null terminated array" {
or using the shorthand function {#syntax#}std.meta.Vector{#endsyntax#}.
- Vectors support the same builtin operators as their underlying base types. These operations are performed
+ Vectors support the same builtin operators as their underlying base types. These operations are performed
element-wise, and return a vector of the same length as the input vectors. This includes:
- It is prohibited to use a math operator on a mixture of scalars (individual numbers) and vectors.
- Zig provides the {#link|@splat#} builtin to easily convert from scalars to vectors, and it supports {#link|@reduce#}
- and array indexing syntax to convert from vectors to scalars. Vectors also support assignment to and from
+ It is prohibited to use a math operator on a mixture of scalars (individual numbers) and vectors.
+ Zig provides the {#link|@splat#} builtin to easily convert from scalars to vectors, and it supports {#link|@reduce#}
+ and array indexing syntax to convert from vectors to scalars. Vectors also support assignment to and from
fixed-length arrays with comptime known length.
For rearranging elements within and between vectors, Zig provides the {#link|@shuffle#} and {#link|@select#} functions.
- Operations on vectors shorter than the target machine's native SIMD size will typically compile to single SIMD
- instructions, while vectors longer than the target machine's native SIMD size will compile to multiple SIMD
- instructions. If a given operation doesn't have SIMD support on the target architecture, the compiler will default
- to operating on each vector element one at a time. Zig supports any comptime-known vector length up to 2^32-1,
- although small powers of two (2-64) are most typical. Note that excessively long vector lengths (e.g. 2^20) may
+ Operations on vectors shorter than the target machine's native SIMD size will typically compile to single SIMD
+ instructions, while vectors longer than the target machine's native SIMD size will compile to multiple SIMD
+ instructions. If a given operation doesn't have SIMD support on the target architecture, the compiler will default
+ to operating on each vector element one at a time. Zig supports any comptime-known vector length up to 2^32-1,
+ although small powers of two (2-64) are most typical. Note that excessively long vector lengths (e.g. 2^20) may
result in compiler crashes on current versions of Zig.
{#code_begin|test|vector_example#}
@@ -2563,7 +2589,7 @@ test "Conversion between vectors, arrays, and slices" {
TODO consider suggesting std.MultiArrayList
{#see_also|@splat|@shuffle|@select|@reduce#}
-
+
{#header_close#}
{#header_open|Pointers#}
@@ -2582,7 +2608,7 @@ test "Conversion between vectors, arrays, and slices" {
{#syntax#}T{#endsyntax#} must have a known size, which means that it cannot be
- {#syntax#}c_void{#endsyntax#} or any other {#link|opaque type|opaque#}.
+ {#syntax#}anyopaque{#endsyntax#} or any other {#link|opaque type|opaque#}.
@@ -2981,8 +3007,8 @@ test "null terminated slice" {
}
{#code_end#}
- Sentinel-terminated slices can also be created using a variation of the slice syntax
- {#syntax#}data[start..end :x]{#endsyntax#}, where {#syntax#}data{#endsyntax#} is a many-item pointer,
+ Sentinel-terminated slices can also be created using a variation of the slice syntax
+ {#syntax#}data[start..end :x]{#endsyntax#}, where {#syntax#}data{#endsyntax#} is a many-item pointer,
array or slice and {#syntax#}x{#endsyntax#} is the sentinel value.
- Sentinel-terminated slicing asserts that the element in the sentinel position of the backing data is
+ Sentinel-terminated slicing asserts that the element in the sentinel position of the backing data is
actually the sentinel value. If this is not the case, safety-protected {#link|Undefined Behavior#} results.
{#code_begin|test_safety|sentinel mismatch#}
@@ -3008,10 +3034,10 @@ const expect = std.testing.expect;
test "sentinel mismatch" {
var array = [_]u8{ 3, 2, 1, 0 };
-
- // Creating a sentinel-terminated slice from the array with a length of 2
- // will result in the value `1` occupying the sentinel element position.
- // This does not match the indicated sentinel value of `0` and will lead
+
+ // Creating a sentinel-terminated slice from the array with a length of 2
+ // will result in the value `1` occupying the sentinel element position.
+ // This does not match the indicated sentinel value of `0` and will lead
// to a runtime panic.
var runtime_length: usize = 2;
const slice = array[0..runtime_length :0];
@@ -3159,7 +3185,12 @@ test "linked list" {
.last = &node,
.len = 1,
};
+
+ // When using a pointer to a struct, fields can be accessed directly,
+ // without explicitly dereferencing the pointer.
+ // So you can do
try expect(list2.first.?.data == 1234);
+ // instead of try expect(list2.first.?.*.data == 1234);
}
{#code_end#}
@@ -3486,7 +3517,7 @@ fn dump(args: anytype) !void {
The fields are implicitly named using numbers starting from 0. Because their names are integers,
- the {#syntax#}@"0"{#endsyntax#} syntax must be used to access them. Names inside {#syntax#}@""{#endsyntax#} are always recognised as identifiers.
+ the {#syntax#}@"0"{#endsyntax#} syntax must be used to access them. Names inside {#syntax#}@""{#endsyntax#} are always recognised as {#link|identifiers|Identifiers#}.
Like arrays, tuples have a .len field, can be indexed and work with the ++ and ** operators. They can also be iterated over with {#link|inline for#}.
@@ -3975,7 +4006,7 @@ test "labeled break from labeled block expression" {
{#see_also|Labeled while|Labeled for#}
{#header_open|Shadowing#}
-
Identifiers are never allowed to "hide" other identifiers by using the same name:
+
{#link|Identifiers#} are never allowed to "hide" other identifiers by using the same name:
{#code_begin|test_err|local shadows declaration#}
const pi = 3.14;
@@ -3987,8 +4018,8 @@ test "inside test block" {
}
{#code_end#}
- Because of this, when you read Zig code you can always rely on an identifier to consistently mean
- the same thing within the scope it is defined. Note that you can, however, use the same name if
+ Because of this, when you read Zig code you can always rely on an identifier to consistently mean
+ the same thing within the scope it is defined. Note that you can, however, use the same name if
the scopes are separate:
{#code_begin|test|test_scopes#}
@@ -4026,7 +4057,7 @@ test "switch simple" {
1, 2, 3 => 0,
// Ranges can be specified using the ... syntax. These are inclusive
- // both ends.
+ // of both ends.
5...100 => 1,
// Branches can be arbitrarily complex.
@@ -4798,7 +4829,7 @@ test "errdefer unwinding" {
{#header_open|Basics#}
{#code_begin|test|test_unreachable#}
-// unreachable is used to assert that control flow will never happen upon a
+// unreachable is used to assert that control flow will never reach a
// particular location:
test "basic math" {
const x = 1;
@@ -6269,8 +6300,8 @@ test "turn HashMap into a set with void" {
value is deleted, as seen above.
- {#syntax#}void{#endsyntax#} is distinct from {#syntax#}c_void{#endsyntax#}.
- {#syntax#}void{#endsyntax#} has a known size of 0 bytes, and {#syntax#}c_void{#endsyntax#} has an unknown, but non-zero, size.
+ {#syntax#}void{#endsyntax#} is distinct from {#syntax#}anyopaque{#endsyntax#}.
+ {#syntax#}void{#endsyntax#} has a known size of 0 bytes, and {#syntax#}anyopaque{#endsyntax#} has an unknown, but non-zero, size.
Expressions of type {#syntax#}void{#endsyntax#} are the only ones whose value can be ignored. For example:
@@ -6766,8 +6797,7 @@ test "variable values" {
generic data structure.
- Here is an example of a generic {#syntax#}List{#endsyntax#} data structure, that we will instantiate with
- the type {#syntax#}i32{#endsyntax#}. In Zig we refer to the type as {#syntax#}List(i32){#endsyntax#}.
+ Here is an example of a generic {#syntax#}List{#endsyntax#} data structure.
{#code_begin|syntax#}
fn List(comptime T: type) type {
@@ -6776,27 +6806,46 @@ fn List(comptime T: type) type {
len: usize,
};
}
+
+// The generic List data structure can be instantiated by passing in a type:
+var buffer: [10]i32 = undefined;
+var list = List(i32){
+ .items = &buffer,
+ .len = 0,
+};
{#code_end#}
- That's it. It's a function that returns an anonymous {#syntax#}struct{#endsyntax#}. For the purposes of error messages
- and debugging, Zig infers the name {#syntax#}"List(i32)"{#endsyntax#} from the function name and parameters invoked when creating
+ That's it. It's a function that returns an anonymous {#syntax#}struct{#endsyntax#}.
+ To keep the language small and uniform, all aggregate types in Zig are anonymous.
+ For the purposes of error messages and debugging, Zig infers the name
+ {#syntax#}"List(i32)"{#endsyntax#} from the function name and parameters invoked when creating
the anonymous struct.
- To keep the language small and uniform, all aggregate types in Zig are anonymous. To give a type
- a name, we assign it to a constant:
+ To explicitly give a type a name, we assign it to a constant.
- This works because all top level declarations are order-independent, and as long as there isn't
- an actual infinite regression, values can refer to themselves, directly or indirectly. In this case,
- {#syntax#}Node{#endsyntax#} refers to itself as a pointer, which is not actually an infinite regression, so
- it works fine.
+ In this example, the {#syntax#}Node{#endsyntax#} struct refers to itself.
+ This works because all top level declarations are order-independent.
+ As long as the compiler can determine the size of the struct, it is free to refer to itself.
+ In this case, {#syntax#}Node{#endsyntax#} refers to itself as a pointer, which has a
+ well-defined size at compile time, so it works fine.
{#header_close#}
{#header_open|Case Study: print in Zig#}
@@ -7209,10 +7258,10 @@ test "global assembly" {
provided explicitly by the caller, and it can be suspended and resumed any number of times.
- The code following the {#syntax#}async{#endsyntax#} callsite runs immediately after the async
- function first suspends. When the return value of the async function is needed,
- the calling code can {#syntax#}await{#endsyntax#} on the async function frame.
- This will suspend the calling code until the async function completes, at which point
+ The code following the {#syntax#}async{#endsyntax#} callsite runs immediately after the async
+ function first suspends. When the return value of the async function is needed,
+ the calling code can {#syntax#}await{#endsyntax#} on the async function frame.
+ This will suspend the calling code until the async function completes, at which point
execution resumes just after the {#syntax#}await{#endsyntax#} callsite.
@@ -7322,8 +7371,8 @@ fn testResumeFromSuspend(my_result: *i32) void {
in standard code.
- However, it is possible to have an {#syntax#}async{#endsyntax#} call
- without a matching {#syntax#}await{#endsyntax#}. Upon completion of the async function,
+ However, it is possible to have an {#syntax#}async{#endsyntax#} call
+ without a matching {#syntax#}await{#endsyntax#}. Upon completion of the async function,
execution would continue at the most recent {#syntax#}async{#endsyntax#} callsite or {#syntax#}resume{#endsyntax#} callsite,
and the return value of the async function would be lost.
@@ -7360,8 +7409,8 @@ fn func() void {
{#syntax#}await{#endsyntax#} is a suspend point, and takes as an operand anything that
- coerces to {#syntax#}anyframe->T{#endsyntax#}. Calling {#syntax#}await{#endsyntax#} on
- the frame of an async function will cause execution to continue at the
+ coerces to {#syntax#}anyframe->T{#endsyntax#}. Calling {#syntax#}await{#endsyntax#} on
+ the frame of an async function will cause execution to continue at the
{#syntax#}await{#endsyntax#} callsite once the target function completes.
Note that even when using {#syntax#}export{#endsyntax#}, {#syntax#}@"foo"{#endsyntax#} syntax can
- be used to choose any string for the symbol name:
+
Note that even when using {#syntax#}export{#endsyntax#}, the {#syntax#}@"foo"{#endsyntax#} syntax for
+ {#link|identifiers|Identifiers#} can be used to choose any string for the symbol name:
{#code_begin|obj#}
export fn @"A function name that is a complete sentence."() void {}
{#code_end#}
@@ -8518,6 +8567,9 @@ test "@hasDecl" {
{#syntax#}@import("builtin"){#endsyntax#} - Target-specific information
The command zig build-exe --show-builtin outputs the source to stdout for reference.
+
{#syntax#}@import("root"){#endsyntax#} - Points to the root source file
+ This is usually `src/main.zig` but it depends on what file is chosen to be built.
+
{#see_also|Compile Variables|@embedFile#}
{#header_close#}
@@ -8529,6 +8581,16 @@ test "@hasDecl" {
Attempting to convert a number which is out of range of the destination type results in
safety-protected {#link|Undefined Behavior#}.
+ {#code_begin|test_err|cast truncated bits#}
+test "integer cast panic" {
+ var a: u16 = 0xabcd;
+ var b: u8 = @intCast(u8, a);
+ _ = b;
+}
+ {#code_end#}
+
+ To truncate the significant bits of a number out of range of the destination type, use {#link|@truncate#}.
+
If {#syntax#}T{#endsyntax#} is {#syntax#}comptime_int{#endsyntax#},
then this is semantically equivalent to {#link|Type Coercion#}.
@@ -8573,7 +8635,9 @@ test "@hasDecl" {
{#header_open|@intToPtr#}
- Converts an integer to a {#link|pointer|Pointers#}. To convert the other way, use {#link|@ptrToInt#}.
+ Converts an integer to a {#link|pointer|Pointers#}. To convert the other way, use {#link|@ptrToInt#}. Casting an address of 0 to a destination type
+ which in not {#link|optional|Optional Pointers#} and does not have the {#syntax#}allowzero{#endsyntax#} attribute will result in a
+ {#link|Pointer Cast Invalid Null#} panic when runtime safety checks are enabled.
If the destination pointer type does not allow address zero and {#syntax#}address{#endsyntax#}
@@ -8687,7 +8751,8 @@ test "@wasmMemoryGrow" {
Modulus division. For unsigned integers this is the same as
- {#syntax#}numerator % denominator{#endsyntax#}. Caller guarantees {#syntax#}denominator > 0{#endsyntax#}.
+ {#syntax#}numerator % denominator{#endsyntax#}. Caller guarantees {#syntax#}denominator > 0{#endsyntax#}, otherwise the
+ operation will result in a {#link|Remainder Division by Zero#} when runtime safety checks are enabled.
{#syntax#}@mod(-5, 3) == 1{#endsyntax#}
@@ -8705,7 +8770,7 @@ test "@wasmMemoryGrow" {
If no overflow or underflow occurs, returns {#syntax#}false{#endsyntax#}.
{#header_close#}
-
+
{#header_open|@panic#}
Remainder division. For unsigned integers this is the same as
- {#syntax#}numerator % denominator{#endsyntax#}. Caller guarantees {#syntax#}denominator > 0{#endsyntax#}.
+ {#syntax#}numerator % denominator{#endsyntax#}. Caller guarantees {#syntax#}denominator > 0{#endsyntax#}, otherwise the
+ operation will result in a {#link|Remainder Division by Zero#} when runtime safety checks are enabled.
Changes the maximum number of backwards branches that compile-time code
execution can use before giving up and making a compile error.
@@ -8896,7 +8962,7 @@ test "foo" {
{#header_close#}
{#header_open|@setFloatMode#}
-
@@ -9372,17 +9438,11 @@ fn List(comptime T: type) type {
or same-sized integer type.
- The following produces safety-checked {#link|Undefined Behavior#}:
+ This function always truncates the significant bits of the integer, regardless
+ of endianness on the target platform.
- However this is well defined and working code:
+ Calling {#syntax#}@truncate{#endsyntax#} on a number out of range of the destination type is well defined and working code:
- This function always truncates the significant bits of the integer, regardless
- of endianness on the target platform.
+ Use {#link|@intCast#} to convert numbers guaranteed to fit the destination type.
{#header_close#}
@@ -9448,9 +9507,14 @@ test "integer truncation" {
Provides type reflection.
- For {#link|structs|struct#}, {#link|unions|union#}, {#link|enums|enum#}, and
- {#link|error sets|Error Set Type#}, the fields are guaranteed to be in the same
- order as declared. For declarations, the order is unspecified.
+ Type information of {#link|structs|struct#}, {#link|unions|union#}, {#link|enums|enum#}, and
+ {#link|error sets|Error Set Type#} has fields which are are guaranteed to be in the same
+ order as appearance in the source file.
+
+
+ Type information of {#link|structs|struct#}, {#link|unions|union#}, {#link|enums|enum#}, and
+ {#link|opaques|opaque#} has declarations, which are also guaranteed to be in the same
+ order as appearance in the source file.