This patch does the same thing as r365595 to other subdirectories,
which completes the naming style change for the entire lld directory.
With this, the naming style conversion is complete for lld.
Differential Revision: https://reviews.llvm.org/D64473
llvm-svn: 365730
This puts handling of undefined symbols in a single location. Its
also more in line with the ELF backend which only reports undefined
symbols based on relocations.
One side effect is that we no longer report undefined symbols that are
only referenced in GC'd sections.
This also fixes a crash reported in the emscripten toolchain:
https://github.com/emscripten-core/emscripten/issues/8930.
Differential Revision: https://reviews.llvm.org/D64280
llvm-svn: 365553
When function signatures don't match and the undefined function is not
called directly (i.e. only has its address taken) we don't issue a
warning or create a runtime thunk for the undefined function.
Instead in this case we simply use the defined version of the function.
This is possible since checking signatures of dynamic calls happens
at runtime so any invalid usage will still result in a runtime error.
This is needed to allow C++ programs to link without generating
warnings. Its not uncommon in C++ for vtables to be populated by
function address whee the signature of the function is not known in the
compilation unit. In this case clang declares the method as void(void)
and relies on the vtable caller casting the data back to the correct
signature.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=40412
Differential Revision: https://reviews.llvm.org/D62153
llvm-svn: 361678
This reverts commit 7804dbddcc.
This change broke a bunch of tests of the WebAssembly waterfall.
Will hopefully reland with increased test coverage.
llvm-svn: 361273
But don't apply comdat groups when loading the LTO object files.
This is basically the same logic used by the ELF linker.
Differential Revision: https://reviews.llvm.org/D61924
llvm-svn: 360782
Previously we could emit a warning and generate a potentially invalid
wasm module (due to call sites and functions having conflicting
signatures). Now, rather than create invalid binaries we handle such
cases by creating stub functions containing unreachable, effectively
turning these into runtime errors rather than validation failures.
Differential Revision: https://reviews.llvm.org/D57909
llvm-svn: 354528
Add a flag to allow symbols to have a wasm import name which differs from the
linker symbol name, allowing the linker to link code using the import_module
attribute.
Differential Revision: https://reviews.llvm.org/D57632
llvm-svn: 353473
Fixes: https://bugs.llvm.org/show_bug.cgi?id=37168
This is only a first pass at supporting these custom import
modules. In the long run we most likely want to treat these
kinds of symbols very differently. For example, it should not
be possible to resolve such as symbol at static link type.
Differential Revision: https://reviews.llvm.org/D45796
llvm-svn: 352828
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This reduces the number of lookups to one per COMDAT group, rather than
one per symbol in a COMDAT group.
Differential Revision: https://reviews.llvm.org/D44344
llvm-svn: 327523
Previously we created __wasm_call_ctors with null InputFunction, and
added the InputFunction later. Now we create the SyntheticFunction with
null body, and set the body later.
Differential Revision: https://reviews.llvm.org/D44206
llvm-svn: 327149
Previously, one function adds all types of undefined symbols. That
doesn't fit to the wasm's undefined symbol semantics well because
different types of undefined symbols are very different in wasm.
As a result, separate control flows merge in this addUndefined function
and then separate again for each type. That wasn't easy to read.
This patch separates the function into three functions. Now it is pretty
clear what we are doing for each undefined symbol type.
Differential Revision: https://reviews.llvm.org/D43697
llvm-svn: 326271
Purely a rename in preparation for adding new global symbol type.
We want to use GlobalSymbol to represent real wasm globals and
DataSymbol for pointers to things in linear memory (what ELF would
call STT_OBJECT).
This reduces the size the patch to add the explicit symbol table
which is coming soon!
Differential Revision: https://reviews.llvm.org/D43476
llvm-svn: 325645
The profailing style in lld seem to be to not include such empty lines.
Clang-tidy/clang-format seem to handle this just fine.
Differential Revision: https://reviews.llvm.org/D43528
llvm-svn: 325629
This brings wasm into line with ELF and COFF in terms of
symbol types are represented.
Differential Revision: https://reviews.llvm.org/D43112
llvm-svn: 325150
These were duplicating (incorrectly) some of the logic for
handling conflicts, but since they are only ever added right
at the start we can assume no existing symbols.
Also rename these methods for clarity.
Differential Revision: https://reviews.llvm.org/D43252
llvm-svn: 325045
Summary:
Rather than explicit Function or InputSegment points store a
pointer to the base class (InputChunk) and use llvm dynamic
casts when we need a subtype.
This change is useful for add the upcoming gc-section support
wants to deal with all input chunks.
Subscribers: aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D42625
llvm-svn: 323621
See https://bugs.llvm.org/show_bug.cgi?id=35533, and D40844
Things covered:
* Removing duplicate data segments (as determined by COMDATs emitted
by the frontend)
* Removing duplicate globals and functions in COMDATs
* Checking that each time a COMDAT is seen it has the same symbols
as at other times (ie it's a stronger check than simply giving all
the symbols in the COMDAT weak linkage)
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D40845
llvm-svn: 322415
This WasmSymbol types comes directly from the input objects
but we want to be able to represent synthetic symbols too.
This is more in line with how the ELF linker represents symbols.
This change also removes the logic from Symbol::getVirtualAddress
for finding the global address and instead has the InputFile
provide this.
Differential Revision: https://reviews.llvm.org/D41426
llvm-svn: 322145
The code section is now written out one function
at a time rather than all the functions in a given
objects being serialized at once.
This change lays the groundwork for supporting
--gc-sections.
Differential Revision: https://reviews.llvm.org/D41315
llvm-svn: 322138
This change cleans up the way wasm exports and globals
are generated, particualrly for -r/--relocatable where
globals need to be created and exported in order for
output relocations which reference them.
Remove the need for a per file GlobalIndexOffset and
instead set the output index for each symbol directly.
This simplifies the code in several places.
Differential Revision: https://reviews.llvm.org/D40859
llvm-svn: 320001
This change allows checking of function signatures but
does not yes enable it by default. In this mode, linking
two objects that were compiled with a different signatures
for the same function will produce a link error.
New options for enabling and disabling this feature have been
added: (--check-signatures/--no-check-signatures).
Differential Revision: https://reviews.llvm.org/D40371
llvm-svn: 319396
This linker backend is still a work in progress but is
enough to link simple programs including linking against
library archives.
Differential Revision: https://reviews.llvm.org/D34851
llvm-svn: 318539
Fangrui Song