vendor/lld/lld-trunk-r351319

11 files changed, 299 insertions, 54 deletions

diff --git a/docs/NewLLD.rst b/docs/NewLLD.rst
index afdb41e0a145..79bdf90c6ccd 100644
--- a/docs/NewLLD.rst
+++ b/docs/NewLLD.rst
@@ -53,7 +53,7 @@ between speed, simplicity and extensibility.
   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 handler (which is typically just a pointer to actual data)
+  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
@@ -90,18 +90,18 @@ between speed, simplicity and extensibility.
   `--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 makes the linker slower.
+  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 link
-  it.  It is doable because LLD does not forget symbols it have seen in archive
+  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 the LLD's way is efficient and easy to justify.
+  We believe that LLD's way is efficient and easy to justify.
 
-  The semantics of LLD's archive handling is different from the traditional
+  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.
@@ -157,7 +157,7 @@ functions, the code of the linker should look obvious to you.
   - 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 archieve members.
+    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
diff --git a/docs/README.txt b/docs/README.txt
index eb09a2d2b7ea..2ed016639de7 100644
--- a/docs/README.txt
+++ b/docs/README.txt
@@ -6,7 +6,4 @@ currently tested with Sphinx 1.1.3.
 
 We currently use the 'nature' theme and a Beaker inspired structure.
 
-To rebuild documents into html:
-
-   [/lld/docs]> make html
-
+See sphinx_intro.rst for more details.
diff --git a/docs/Readers.rst b/docs/Readers.rst
index b69a0b34fabe..eae1717f6e5b 100644
--- a/docs/Readers.rst
+++ b/docs/Readers.rst
@@ -74,7 +74,7 @@ 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 method to implement in a reader is::
+The key function to implement in a reader is::
 
   virtual error_code loadFile(LinkerInput &input,
                               std::vector<std::unique_ptr<File>> &result);
diff --git a/docs/ReleaseNotes.rst b/docs/ReleaseNotes.rst
index 7ac1f9ce565b..dc5df6795d99 100644
--- a/docs/ReleaseNotes.rst
+++ b/docs/ReleaseNotes.rst
@@ -1,22 +1,22 @@
 =======================
-LLD 7.0.0 Release Notes
+lld 8.0.0 Release Notes
 =======================
 
 .. contents::
     :local:
 
 .. warning::
-   These are in-progress notes for the upcoming LLVM 7.0.0 release.
+   These are in-progress notes for the upcoming LLVM 8.0.0 release.
    Release notes for previous releases can be found on
-   `the Download Page <http://releases.llvm.org/download.html>`_.
+   `the Download Page <https://releases.llvm.org/download.html>`_.
 
 Introduction
 ============
 
-This document contains the release notes for the lld linker, release 7.0.0.
+This document contains the release notes for the lld linker, release 8.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 <http://llvm.org/releases/>`_.
+from the `LLVM releases web site <https://llvm.org/releases/>`_.
 
 Non-comprehensive list of changes in this release
 =================================================
@@ -24,14 +24,57 @@ Non-comprehensive list of changes in this release
 ELF Improvements
 ----------------
 
-* Item 1.
+* lld now supports RISC-V. (`r339364
+  <https://reviews.llvm.org/rL339364>`_)
+
+* Default image base address has changed from 65536 to 2 MiB for i386
+  and 4 MiB for AArch64 to make lld-generated executables work better
+  with automatic superpage promotion. FreeBSD can promote contiguous
+  non-superpages to a superpage if they are aligned to the superpage
+  size. (`r342746 <https://reviews.llvm.org/rL342746>`_)
+
+* lld/Hexagon can now link Linux kernel and musl libc for Qualcomm
+  Hexagon ISA.
+
+* Initial MSP430 ISA support has landed.
+
+* The following flags have been added: ``-z interpose``, ``-z global``
 
 COFF Improvements
 -----------------
 
-* Item 1.
+* PDB GUID is set to hash of PDB contents instead to a random byte
+  sequence for build reproducibility.
+
+* The following flags have been added: ``/force:multiple``
+
+* lld now can link against import libraries produced by GNU tools.
+
+* lld can create thunks for ARM, to allow linking images over 16 MB.
+
+MinGW Improvements
+------------------
+
+* lld can now automatically import data variables from DLLs without the
+  use of the dllimport attribute.
+
+* lld can now use existing normal MinGW sysroots with import libraries and
+  CRT startup object files for GNU binutils. lld can handle most object
+  files produced by GCC, and thus works as a drop-in replacement for
+  ld.bfd in such environments. (There are known issues with linking crtend.o
+  from GCC in setups with DWARF exceptions though, where object files are
+  linked in a different order than with GNU ld, inserting a DWARF exception
+  table terminator too early.)
 
 MachO Improvements
 ------------------
 
 * Item 1.
+
+WebAssembly Improvements
+------------------------
+
+* Add initial support for creating shared libraries (-shared).
+  Note: The shared library format is still under active development and may
+  undergo significant changes in future versions.
+  See: https://github.com/WebAssembly/tool-conventions/blob/master/DynamicLinking.md
diff --git a/docs/WebAssembly.rst b/docs/WebAssembly.rst
index 264d221970b1..424c1a10c7e7 100644
--- a/docs/WebAssembly.rst
+++ b/docs/WebAssembly.rst
@@ -1,13 +1,10 @@
 WebAssembly lld port
 ====================
 
-Note: The WebAssembly port is still a work in progress and is be lacking
-certain features.
-
 The WebAssembly version of lld takes WebAssembly binaries as inputs and produces
-a WebAssembly binary as its output.  For the most part this port tried to mimic
-the behaviour of traditional ELF linkers and specifically the ELF lld port.
-Where possible that command line flags and the semantics should be the same.
+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 that command line flags and the semantics should be the same.
 
 
 Object file format
@@ -23,14 +20,95 @@ currently requires enabling the experimental backed using
 ``-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly``.
 
 
+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)
+
+.. option:: --export-dynamic
+
+  When building an executable, export any non-hidden symbols.  By default only
+  the entry point and any symbols marked with --export/--export-all are
+  exported.
+
+.. option:: --global-base=<value>
+
+  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 5-bytes wide in order to potentially
+  occomate the largest LEB128 value.  This option will cause the linker to
+  shirnk the code section to remove any padding from the final output.  However
+  because it effects code offset, this option is not comatible with outputing
+  debug information.
+
+.. option:: --allow-undefined
+
+  Allow undefined symbols in linked binary.
+
+.. option:: --import-memory
+
+  Import memory from the environment.
+
+.. option:: --initial-memory=<value>
+
+  Initial size of the linear memory. Default: static data size.
+
+.. option:: --max-memory=<value>
+
+  Maximum size of the linear memory. Default: unlimited.
+
+By default the function table is neither imported nor exported, but defined
+for internal use only.
+
+When building shared libraries symbols are exported if they are marked
+as ``visibility=default``.  When building executables only the entry point is
+exported by default.  In addition any symbol included on the command line via
+``--export`` is also exported.
+
+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.
+
+
 Missing features
 ----------------
 
-There are several key features that are not yet implement in the WebAssembly
-ports:
-
-- COMDAT support.  This means that support for C++ is still very limited.
-- Function stripping.  Currently there is no support for ``--gc-sections`` so
-  functions and data from a given object will linked as a unit.
-- Section start/end symbols.  The synthetic symbols that mark the start and
-  of data regions are not yet created in the output file.
+- 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
diff --git a/docs/conf.py b/docs/conf.py
index 3598fbf50f0d..62404b275450 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -48,9 +48,9 @@ copyright = u'2011-%d, LLVM Project' % date.today().year
 # built documents.
 #
 # The short version.
-version = '7'
+version = '8'
 # The full version, including alpha/beta/rc tags.
-release = '7'
+release = '8'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
diff --git a/docs/index.rst b/docs/index.rst
index 2821ce4d214e..da1c894f3d83 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -1,7 +1,7 @@
 LLD - The LLVM Linker
 =====================
 
-LLD is a linker from the LLVM project. That is a drop-in replacement
+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.
 
@@ -17,7 +17,7 @@ read :doc:`AtomLLD`.
 Features
 --------
 
-- LLD is a drop-in replacement for the GNU linkers. That accepts the
+- 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
@@ -30,29 +30,27 @@ Features
   <https://www.freebsd.org/news/status/report-2016-10-2016-12.html#Using-LLVM%27s-LLD-Linker-as-FreeBSD%27s-System-Linker>`_.
 
 - 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 GNU
+  machine, you can expect that LLD runs more than twice as fast as the GNU
   gold linker. Your milage may vary, though.
 
 - It supports various CPUs/ABIs including x86-64, x86, x32, AArch64,
   ARM, MIPS 32/64 big/little-endian, PowerPC, PowerPC 64 and AMDGPU.
-  Among these, x86-64 is the most well-supported target and have
-  reached production quality. AArch64 and MIPS seem decent too. x86
-  should be OK but not well tested yet. ARM support is being developed
-  actively.
+  Among these, x86-64, AArch64, and ARM (>= v6) are production quality.
+  MIPS seems decent too. x86 should be OK but is not well tested yet.
 
 - 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 to your program to eliminate dependency to
+- 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 completely a fair comparison, but as of February
+  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.
 
@@ -102,8 +100,8 @@ under ``tools`` directory just like you probably did for clang. For the
 details, see `Getting Started with the LLVM System
 <http://llvm.org/docs/GettingStarted.html>`_.
 
-If you haven't checkout out LLVM, the easiest way to build LLD is to
-checkout the entire LLVM projects/sub-projects from a git mirror and
+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
diff --git a/docs/ld.lld.1 b/docs/ld.lld.1
index 0fdfe0ae7e89..d1ce4a3517f4 100644
--- a/docs/ld.lld.1
+++ b/docs/ld.lld.1
@@ -3,7 +3,7 @@
 .\"
 .\" This man page documents only lld's ELF linking support, obtained originally
 .\" from FreeBSD.
-.Dd July 30, 2018
+.Dd September 26, 2018
 .Dt LD.LLD 1
 .Os
 .Sh NAME
@@ -13,6 +13,7 @@
 .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
@@ -25,7 +26,21 @@ 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
-These options are available:
+.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
 .Bl -tag -width indent
 .It Fl -allow-multiple-definition
 Do not error if a symbol is defined multiple times.
@@ -144,6 +159,9 @@ 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 -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
@@ -297,6 +315,8 @@ Include hotness information in the optimization remarks file.
 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 -push-state
@@ -304,7 +324,7 @@ Save the current state of
 .Fl -as-needed ,
 .Fl -static ,
 and
-.Fl -while-archive.
+.Fl -whole-archive.
 .It Fl -pop-state
 Undo the effect of
 .Fl -push-state.
@@ -426,6 +446,17 @@ This can be used to ensure linker invocation remains compatible with
 traditional Unix-like linkers.
 .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
@@ -440,10 +471,22 @@ Make the main stack executable.
 Stack permissions are recorded in the
 .Dv PT_GNU_STACK
 segment.
+.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.
 .It Cm initfirst
 Sets the
 .Dv DF_1_INITFIRST
 flag to indicate the module should be initialized first.
+.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.
 .It Cm muldefs
 Do not error if a symbol is defined multiple times.
 The first definition will be used.
@@ -453,6 +496,10 @@ This is a synonym for
 Disable combining and sorting multiple relocation sections.
 .It Cm nocopyreloc
 Disable the creation of copy relocations.
+.It Cm nodefaultlib
+Set the
+.Dv DF_1_NODEFLIB
+flag to indicate that default library search paths should be ignored.
 .It Cm nodelete
 Set the
 .Dv DF_1_NODELETE
@@ -460,7 +507,7 @@ flag to indicate that the object cannot be unloaded from a process.
 .It Cm nodlopen
 Set the
 .Dv DF_1_NOOPEN
-flag to indcate that the object may not be opened by
+flag to indicate that the object may not be opened by
 .Xr dlopen 3 .
 .It Cm norelro
 Do not indicate that portions of the object shold be mapped read-only
diff --git a/docs/missingkeyfunction.rst b/docs/missingkeyfunction.rst
new file mode 100644
index 000000000000..410c749c3b03
--- /dev/null
+++ b/docs/missingkeyfunction.rst
@@ -0,0 +1,84 @@
+Missing Key Method
+==================
+
+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 method), 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 method, 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 methods, there is no key
+method, 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 method 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 method, so it is the key
+method. 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 method.
+
+Forgetting to declare a virtual method 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
+methods 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 method 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 method 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/docs/open_projects.rst b/docs/open_projects.rst
index eeb9f9f48f34..36edca4e96dc 100644
--- a/docs/open_projects.rst
+++ b/docs/open_projects.rst
@@ -3,8 +3,6 @@
 Open Projects
 =============
 
-.. include:: ../include/lld/Core/TODO.txt
-
 Documentation TODOs
 ~~~~~~~~~~~~~~~~~~~
 
diff --git a/docs/windows_support.rst b/docs/windows_support.rst
index a0a2c4d9f1bc..c9723c42fcc8 100644
--- a/docs/windows_support.rst
+++ b/docs/windows_support.rst
@@ -20,8 +20,8 @@ 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 can link itself on Windows x86/x64
-using Visual C++ 2013 as the compiler.
+The current status is that LLD is used to link production builds of large
+real-world binaries such as Firefox and Chromium.
 
 Development status
 ==================