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
Summary:
This patch fixes clang-tidy warnings on wasm-only files.
The list of checks used is:
`-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,readability-identifier-naming,modernize-*`
(LLVM's default .clang-tidy list is the same except it does not have
`modernize-*`.)
The list of fixes are:
- Variable names start with an uppercase letter
- Function names start with a lowercase letter
- Use `auto` when you use casts so the type is evident
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D57499
llvm-svn: 353076
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
Previously we were never setting this which means it was always being
set to Default (-O2/-Os).
Differential Revision: https://reviews.llvm.org/D57422
llvm-svn: 352667
Change the way we create the symbol table to be closer to how its done
on ELF. Now the output symbol table matches the internal symtab order
and includes local and undefined symbols.
Fixes PR40204
Differential Revision: https://reviews.llvm.org/D56947
llvm-svn: 352645
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 reverts commit 71eaf61c6c121c8c3bcaf3490557e92cf81599cb. One of
the lld tests was breaking, so revert this change until it is fixed.
llvm-svn: 351409
Summary:
At the beginning of `assignIndexes() function, when `FunctionIndex` and
`GlobalIndex` variables are created, `InputFunctions` and `InputGlobals`
vectors are guaranteed to be empty, because those vectors are only
populated in `assignIndexes()` function. Current code looks like they
are nonempty, so this patch deletes them for better readability.
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D54687
llvm-svn: 347272
`--no-demangle` now also applies to the name section. This change
was motivated by the rust team that have a slightly different name
mangling scheme to the standard C++ itanium one and prefer to do their
de-mangling as a post-link setp.
Patch by Alex Crichton!
Differential Revision: https://reviews.llvm.org/D54279
llvm-svn: 346516
Used for WebAssembly threads proposal. Add a flag --shared-memory
which sets the IS_SHARED bit in WasmLimits
Differential Revision: https://reviews.llvm.org/D54130
llvm-svn: 346248
Summary: Before, OptTable::PrintHelp append "[options] <inputs>" to its parameter `Help`. It is more flexible to change its semantic to `Usage` and let user customize the usage line.
Reviewers: rupprecht, ruiu, espindola
Reviewed By: rupprecht
Subscribers: emaste, sbc100, arichardson, aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D53054
llvm-svn: 344099
With LTO when and undefined function (with a known signature)
in replaced by a defined bitcode function we were loosing the
signature information (since bitcode functions don't have
signatures).
With this change we preserve the original signature from the
undefined function and verify that the post LTO compiled
function has the correct signature.
This change improves the error handling in the case where
there is a signature mismatch with a function defined in
a bitcode file.
Differential Revision: https://reviews.llvm.org/D50721
llvm-svn: 343340
In a very recent change I introduced a --no-export-default flag
but after conferring with others it seems that this feature already
exists in gnu GNU ld and lld in the form the --export-dynamic flag
which is off by default.
This change replaces export-default with export-dynamic and also
changes the default to match the traditional linker behaviour.
Now, by default, only the entry point is exported. If other symbols
are required by the embedder then --export-dynamic or --export can
be used to export all visibility hidden symbols or individual
symbols respectively.
This change touches a lot of tests that were relying on symbols
being exported by default. I imagine it will also effect many
users but do think the change is worth it match of the traditional
behaviour and flag names.
Differential Revision: https://reviews.llvm.org/D52587
llvm-svn: 343265
These option control weather or not symbols marked as visibility
default are exported in the output binary.
By default this is true, but emscripten prefers to control the
exported symbol list explicitly at link time and ignore the
symbol attributes.
Differential Revision: https://reviews.llvm.org/D52003
llvm-svn: 343034
Summary:
Currently we are pointing all debug information that refer removed function code
to the beginning of the code section (offset = 0). A debugger may want to
resolve code offset to the debug information, which will collide with offsets
of the live functions.
Moving offsets of dead functions outside code section range.
Reviewers: sbc100
Reviewed By: sbc100
Subscribers: dblaikie, ruiu, alexcrichton, dschuff, aprantl, jgravelle-google, aheejin, sunfish, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D49446
llvm-svn: 342930
This is a minor follow-up to https://reviews.llvm.org/D49189. On Windows, lld
used to print "lld-link.exe: error: ...". Now it just prints "lld-link: error:
...". This matches what link.exe does (it prints "LINK : ...") and makes lld's
output less dependent on the host system.
https://reviews.llvm.org/D51133
llvm-svn: 340487
LEB compression breaks debug info so we don't want to enable
it by default, even at high optimization levels.
Differential Revision: https://reviews.llvm.org/D50729
llvm-svn: 340073
--export now implies --undefined
This is really a requirement from emscripten but I think it
makes sense in general too.
Differential Revision: https://reviews.llvm.org/D50287
llvm-svn: 339047
This matches the behavior of the ELF linker where -u/--undefined
means symbols will get pulled in from archives but won't result
in link error if they are missing.
Also, don't actually great symbol table entries for the undefined
symbols, again matching more closely the ELF linker.
This also results in simplification of the code.
Differential Revision: https://reviews.llvm.org/D50279
llvm-svn: 338938
lld currently prepends the absolute path to itself to every diagnostic it
emits. This path can be longer than the diagnostic, and makes the actual error
message hard to read.
There isn't a good reason for printing this path: if you want to know which lld
you're running, pass -v to clang – chances are that if you're unsure of this,
you're not only unsure when it errors out. Some people want an indication that
the diagnostic is from the linker though, so instead print just the basename of
the linker's path.
Before:
```
$ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crt1.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crti.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtbegin.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtend.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
After:
```
$ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld
ld.lld: error: cannot open crt1.o: No such file or directory
ld.lld: error: cannot open crti.o: No such file or directory
ld.lld: error: cannot open crtbegin.o: No such file or directory
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: unable to find library -lc
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: cannot open crtend.o: No such file or directory
ld.lld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
https://reviews.llvm.org/D49189
llvm-svn: 337634
This change effects the behavior of --export-all. Previously
--export-all would only effect symbols that survived GC. Now
--export-all will prevent any non-local symbols from being GCed.
Differential Revision: https://reviews.llvm.org/D48673
llvm-svn: 335878
Function symbols that come from bitcode have not signatures.
After LTO when the real symbols are read in we need to make
sure that we set the signature on the existing symbol.
the signature-less undefined functions.
Differential Revision: https://reviews.llvm.org/D48693
llvm-svn: 335875
This caused a lot of issues on the WebAssembly waterfall.
In particular, until with the signature of `main`. We
probably want a better solution for main before we re-land.
Reverts rL335192
llvm-svn: 335355
During symbol resolution, emit warnings for function signature
mismatches. During GC, if any mismatched symbol is marked as live
then generate an error.
This means that we only error out if the mismatch is written to the
final output. i.e. if we would generate an invalid wasm file.
Differential Revision: https://reviews.llvm.org/D48394
llvm-svn: 335192
WebAssembly depends on attributes.h which includes attributes.inc.
Unless cmake explicitly specifies this dependency, the .inc file
is sometimes generated after the build tries to use it.
Patch by Stella Stamenova
llvm-svn: 334581
This causes all symbols to be exported in the final wasm binary
even if they were not compiled with default visibility.
This feature is useful for the emscripten toolchain that has a
corresponding EXPORT_ALL feature which allows the JS code to
interact with all C function.
Differential Revision: https://reviews.llvm.org/D47806
llvm-svn: 334157
When a symbol is GC'd it can still be references by relocations
in the debug sections, but such symbols are not assigned virtual
addresses.
This change adds a new global data symbol which gets GC'd but
should still appears in the output debug info, albeit with a 0
address.
Fixes 37555
Differential Revision: https://reviews.llvm.org/D47238
llvm-svn: 333047
There are only certain relocation types that can exist in the
wasm code section and they are all LEB types. Remove the dead
code for handling the other (I32) reloc types.
Differential Revision: https://reviews.llvm.org/D47226
llvm-svn: 333030
* Gets function size field from right location
* Writes I32 values during compression
Patch by Yury Delendik
Differential Revision: https://reviews.llvm.org/D47204
llvm-svn: 333002
This change adds the ability for lld to remove LEB padding from
code section. This effectively shrinks the size of the resulting
binary in proportion to the number of code relocations.
Since there will be a performance cost this is currently only active for
-O1 and above. Some toolchains may instead want to perform this
compression as a post linker step (for example running a binary through
binaryen will automatically compress these values).
I imagine we might want to make this the default in the future.
Differential Revision: https://reviews.llvm.org/D46416
llvm-svn: 332783
Provide some free functions to reduce verbosity of endian-writing
a single value, and replace the endianness template parameter with
a field.
Part of PR37466.
Differential Revision: https://reviews.llvm.org/D47032
llvm-svn: 332757
Fixes: lld: warning: unexpected existing value for R_WEBASSEMBLY_FUNCTION_OFFSET_I32: existing=839 expected=838
The existing solution is trying to erroneously recover correct offset of
the function code from the body (which is not a function segment that
includes its size, locals, and code).
The D46763 is trying to maintain the offset of the function code
allowing properly calculate the new relocation entry.
Patch by Yury Delendik
Differential Revision: https://reviews.llvm.org/D46765
llvm-svn: 332412
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
Differential Revision: https://reviews.llvm.org/D44977
llvm-svn: 332351
Since we a no longer using this function for the wasm start
section we don't actually care what its signature is.
Differential Revision: https://reviews.llvm.org/D46594
llvm-svn: 332308
Merging data segments produces smaller code sizes because each segment
has some boilerplate. Therefore, merging data segments is generally the
right approach, especially with wasm where binaries are typically
delivered over the network.
However, when analyzing wasm binaries, it can be helpful to get a
conservative picture of which functions are using which data
segments[0]. Perhaps there is a large data segment that you didn't
expect to be included in the wasm, introduced by some library you're
using, and you'd like to know which library it was. In this scenario,
merging data segments only makes the analysis worse.
Alternatively, perhaps you will remove some dead functions by-hand[1]
that can't be statically proven dead by the compiler or lld, and
removing these functions might make some data garbage collect-able, and
you'd like to run `--gc-sections` again so that this now-unused data can
be collected. If the segments were originally merged, then a single use
of the merged data segment will entrench all of the data.
[0] https://github.com/rustwasm/twiggy
[1] https://github.com/fitzgen/wasm-snip
Patch by Nick Fitzgerald!
Differential Revision: https://reviews.llvm.org/D46417
llvm-svn: 332013
This is most useful when using lld-link on a non-Win host (but it might become
useful on Windows too if lld also grows a fansi-escape-codes flag).
Also make the help for --color-diagnostic mention the valid values in ELF and
wasm, and print the flag name with two dashes in diags, since the one-dash form
is seen as a list of many one-letter flags in some contexts.
https://reviews.llvm.org/D46693
llvm-svn: 332012
Also:
- Reduce the error to a warning so that debug and release
versions can still link the same inputs.
- Add another check to verify the input LEB is padded to 5 bytes
Differential Revision: https://reviews.llvm.org/D46479
llvm-svn: 331571
Specifically add support for custom sections that contain
relocations, and for the two new relocation types needed
by DWARF sections.
See: https://reviews.llvm.org/D44184
Patch by Yury Delendik!
Differential Revision: https://reviews.llvm.org/D44184
llvm-svn: 331566
Enables cleaning up confusion between which name variables are mangled
and which are unmangled, and --print-gc-sections then excersises and
tests that.
Differential Revision: https://reviews.llvm.org/D44440
llvm-svn: 330449
Relocation addends can be negative so should be written as
signed LEBs. This bug meant that writing value between 64
and 128 would be incorrectly interpreted as negative by the
object file readers.
Differential Revision: https://reviews.llvm.org/D45825
llvm-svn: 330374
Summary:
The content of custome sections no longer includes the
name itself.
See: https://reviews.llvm.org/D45579
Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D45580
llvm-svn: 329948
Copy user-defined custom sections into the output, concatenating
sections with the same name.
Differential Revision: https://reviews.llvm.org/D45340
llvm-svn: 329717
Since InputGlobal makes a copy of a given object, we can use a temporary
object allocated on the stack here.
Differential Revision: https://reviews.llvm.org/D43924
llvm-svn: 329337
This enables callback-style programming where the JavaScript environment
can call back into the Wasm environment using a function pointer
received from the module.
Differential Revision: https://reviews.llvm.org/D44427
llvm-svn: 328643
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, Config->InitialMemory/MaxMemory were hooked up to some
commandline args but had no effect at all.
Differential Revision: https://reviews.llvm.org/D44393
llvm-svn: 327508
This fixes issues found on the wasm waterfall related to relocations
with addends. Undefined symbols, even those with addends should
always have a provisional value of zero. At least this is what llvm
emits (and I believe this is true for ELF too).
Differential Revision: https://reviews.llvm.org/D44451
llvm-svn: 327468
Previously, Config->Demangle was uninitialised (not hooked up to
commandline handling)
Differential Revision: https://reviews.llvm.org/D44301
llvm-svn: 327390
Verify that the location where a relocation is about the be
applied contains the expected existing value.
This is essentially a sanity check to catch bugs in the compiler
and the linker.
Differential Revision: https://reviews.llvm.org/D44349
llvm-svn: 327325
This bug was found by accident while trying to expand out testcases
for imported symbols, and is covered by the additional test case.
Differential Revision: https://reviews.llvm.org/D44331
llvm-svn: 327290
This matches the existing ordering that's been there for globals
for a while (__stack_pointer coming first).
Differential Revision: https://reviews.llvm.org/D44333
llvm-svn: 327286
toString(T) is a stringize function for an object of type T. Each type
that has that function defined should know how to stringize itself, and
there should be one string representation of an object. Passing a
"supplemental" argument to toString() breaks that princple. We shouldn't
add a second parameter to that function.
Differential Revision: https://reviews.llvm.org/D44323
llvm-svn: 327182
This error case is described in Linking.md. The operand for call requires
generation of a synthetic stub.
Differential Revision: https://reviews.llvm.org/D44028
llvm-svn: 327151
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
When a symbol is exported via --export=foo but --allow-undefined
is also specified, the symbol is now allowed to be undefined.
Previously we were special casing such symbols.
This combinations of behavior is exactly what emescripten
requires. Although we are trying hard not to allow emscripten
specific features in lld, this one makes sense.
Enforce this behavior by added this case to test/wasm/undefined.ll.
Differential Revision: https://reviews.llvm.org/D44237
llvm-svn: 326976
This avoids the Writer unnecessarily having a member to retain ownership
of the function body.
Differential Revision: https://reviews.llvm.org/D43933
llvm-svn: 326580
Let X and Y be types. Previously, functions F(X, Y) and G(Y, X) had
the same hash value because their hash values are computed as follows:
hash(F) = hash(X) + hash(Y)
hash(G) = hash(Y) + hash(X)
This patch fixes the issue by using hash_combine.
Differential Revision: https://reviews.llvm.org/D43856
llvm-svn: 326336
Richard Trieu