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
Sam Clegg