Commit Graph

450 Commits

Author SHA1 Message Date
Nikita Popov b8f50abd04 [lld] Remove support for legacy pass manager
This removes options for performing LTO with the legacy pass
manager in LLD. Options that explicitly enable the new pass manager
are retained as no-ops.

Differential Revision: https://reviews.llvm.org/D123219
2022-04-07 10:17:31 +02:00
Sam Clegg a04a507714 [lld][WebAssembly] Fix crash accessing non-live __tls_base symbol
In programs that don't otherwise depend on `__tls_base` it won't
be marked as live.  However this symbol is used internally in
a couple of places do we need to mark it as live explictily in
those places.

Fixes: #54386

Differential Revision: https://reviews.llvm.org/D121931
2022-03-17 13:59:45 -07:00
Sam Clegg 4690bf2ed3 [lld][WebAssembly] Take advantage of extended const expressions when available
In particular we use these in two places:

1. When building PIC code we no longer need to combine output segments
   into a single segment that can be initialized at `__memory_base`.
   Instead each segment can encode its offset from `__memory_base` in
   its initializer.  e.g.

```
(i32.add (global.get __memory_base) (i32.const offset)
```

2. When building PIC code we no longer need to relocation internalized
   global addresses.  We can just initialize them with their correct
   offsets.

Differential Revision: https://reviews.llvm.org/D121420
2022-03-15 17:50:05 -07:00
Sam Clegg 86c90f9bfd [lld][WebAssembly] Add --unresolved-symbols=import-dynamic
This is a new mode for handling unresolved symbols that allows all
symbols to be imported in the same that they would be in the case of
`-fpie` or `-shared`, but generting an otherwise fixed/non-relocatable
binary.

Code linked in this way should still be compiled with `-fPIC` so that
data symbols can be resolved via imports.

This essentially allows the building of static binaries that have
dynamic imports.  See:
https://github.com/emscripten-core/emscripten/issues/12682

As with other uses of the experimental dynamic linking ABI, this
behaviour will produce a warning unless run with `--experimental-pic`.

Differential Revision: https://reviews.llvm.org/D91577
2022-03-15 15:10:21 -07:00
Sam Clegg 1cf6ebc0e9 [lld][WebAssembly] Improve error reporting for bad ar archive members
Show the name of of the archive in the error message as well as the name
of the object within it.

Differential Revision: https://reviews.llvm.org/D120689
2022-03-01 15:21:53 -08:00
Sam Clegg 4c75521ce0 [MC][WebAssembly] Fix crash when relocation addend underlows U32
For the object file writer we need to allow the underflow (ar write
zero), but for the final linker output we should probably generate an
error (I've left that as a TODO for now).

Fixes: https://github.com/llvm/llvm-project/issues/54012

Differential Revision: https://reviews.llvm.org/D120522
2022-02-25 07:13:15 -08:00
Sam Clegg 70aa11187e [lld][WebAssembly] Convert a bunch more tests to asm. NFC
Differential Revision: https://reviews.llvm.org/D120060
2022-02-18 16:30:08 -08:00
Sam Clegg dabbab6861 [lld][WebAssembly] Apply global relocs before data relocs
Since the code for apply data relocations can sometimes use
the values stored in he globals, they need to be relocated
before the data relocations can be run.

Fixes: https://github.com/emscripten-core/emscripten/issues/13398

Differential Revision: https://reviews.llvm.org/D119666
2022-02-16 14:30:39 -08:00
Sam Clegg d2a0ef9844 [lld][WebAssembly] Don't force the export symbols assiged internal/dummy GOT entries
Symbols with regular GOT entries do need to be exported, but those that
are internalized (and have dymmy/internal GOT entries) need not be
exported.

This happens to fix the failures on the emscripten waterfall where extra
symbols were being exported by the linker (and then later removed by
wasm-opt).

Differential Revision: https://reviews.llvm.org/D119902
2022-02-15 17:29:45 -08:00
Sam Clegg faab70b783 [lld][WebAssemlby] Warn on unknown -z flags
This code mirrors that in lld/ELF/Driver.cpp, as does the new test code.

Differential Revision: https://reviews.llvm.org/D119888
2022-02-15 14:42:04 -08:00
Sam Clegg 37f422f4ac [WebAssembly] Use GeneralDynamic TLS for exception handling builtins.
These global TLS symbols are shared across all shared libraries and
therefor should not be assumed to be local to the current module.

Also add new error in the linker when TLS relocations are used against
undefined symbols.  TLS relocations are offsets into the current modules
tls data segment, and don't make sense for undefined symbols which are
modeled as global imports.

Fixes: https://github.com/emscripten-core/emscripten/issues/13398

Differential Revision: https://reviews.llvm.org/D119630
2022-02-14 14:08:32 -08:00
Sam Clegg 875ee937ae [lld][WebAssembly] Handle TLS symbols in older object file
In older versions of llvm (e.g. llvm 13), symbols were not individually
flagged as TLS.  In this case, the indent was to implicitly mark any
symbols defined in TLS segments as TLS.  However, we were not performing
this implicit conversion if the segment was explicitly marked as TLS

As it happens, llvm 13 was branched between the addition of the segment
flag and the addition of the symbol flag. See:

- segment flag added: https://reviews.llvm.org/D102202
- symbol flag added: https://reviews.llvm.org/D109426

Testing this is tricky because the assembler will imply the TLS status
of the symbol based on the segment its declared in, so we are forced to
use a yaml file here.

Fixes: https://github.com/emscripten-core/emscripten/issues/15891

Differential Revision: https://reviews.llvm.org/D118414
2022-01-27 17:27:09 -08:00
Sam Clegg feddf11502 [lld][WebAssemlby] Convert test to check disassembly output. NFC
Differential Revision: https://reviews.llvm.org/D117739
2022-01-20 09:32:01 -08:00
Sam Clegg ec47dba1c8 [lld][WebAssembly] Perform data relocations during start function
We already perform memory initialization and apply global relocations
during start.  It makes sense to performs data relocations too.  I think
the reason we were not doing this already is solely historical.

Differential Revision: https://reviews.llvm.org/D117412
2022-01-18 14:08:42 -08:00
Sam Clegg ae1573e131 [lld][WebAssembly] Reinstate mistakenly disabled test. NFC
It seems the first half of this test was disabled in error
as part of https://reviews.llvm.org/D93066.

Differential Revision: https://reviews.llvm.org/D117594
2022-01-18 12:22:22 -08:00
Kristina Bessonova 81378f7e56 Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block" & dependent patches
Try to revert D113741 once again.

This also reverts 0ac75e82ff (D114705)
as it causes LLDB's lldb-api.lang/cpp/nsimport.TestCppNsImport.py test
failure w/o D113741.

This reverts commit f9607d45f3.

Differential Revision: https://reviews.llvm.org/D116225
2021-12-24 00:47:04 +02:00
Kristina Bessonova 0ac75e82ff Reland [DwarfDebug] Move emission of global vars, types and imports to endModule()
This patch proposes to move emission of global variables, types,
imported entities, etc from DwarfDebug::beginModule() to DwarfDebug::endModule().
Effectively, this changes nothing but the order of debug entities which
will be as follows:
* subprograms (including related context, local variables/labels,
  local imported entities; related types can be created as a part of
  the emission of local entities of an abstract subprogram);
* global variables (including related context and types);
* retained types and enums;
* non-local-scoped imported entities;
* basic types;
* other types left (as a part of local variables attributes emission).

Note that the order of emitted compile units may also be changed as now we emit
units that contain subprograms first and then all other non-empty units.

The motivation behind this change is the following:
(1) DwarfDebug::beginModule() is run at the very beginning of backend's pipeline,
    from this time IR can be significantly changed by target-specific passes.
    If it happens for debug metadata of global entities, those changes will not
    be reflected in the emitted DWARF.
(2) imported subprogram names should refer to an abstract subprogram if it exists,
    but it isn't known in DwarfDebug::beginModule() (it's possible to make some
    guesses based on location info, but it's not quite reliable);
(3) aforementioned entities if they are scoped within a bracketed block
    (subject of D113741) couldn't be emitted in DwarfDebug::beginModule()
    (they need parent emitted first). Another problem is if to try to gather
    some information about local entities and defer their emission
    (till subprogram's processing or DwarfDebug::endModule()) all the gathered
    details might be irrelevant / invalid by the time the entities are being
    emitted (because of (1)).

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D114705
2021-12-05 13:56:45 +02:00
Kristina Bessonova a961604819 Revert "[DwarfDebug] Support emitting function-local declaration for a lexical block"
This reverts commits
* ee691970a9 (D113741),
* 79d3132998 (D114705)

due to lldb and dexter test failures.
2021-12-04 18:06:57 +02:00
Kristina Bessonova 79d3132998 [DwarfDebug] Move emission of global vars, types and imports to endModule()
This patch proposes to move emission of global variables, types,
imported entities, etc from DwarfDebug::beginModule() to DwarfDebug::endModule().
Effectively, this changes nothing but the order of debug entities which
will be as follows:
* subprograms (including related context, local variables/labels,
  local imported entities; related types can be created as a part of
  the emission of local entities of an abstract subprogram);
* global variables (including related context and types);
* retained types and enums;
* non-local-scoped imported entities;
* basic types;
* other types left (as a part of local variables attributes emission).

Note that the order of emitted compile units may also be changed as now we emit
units that contain subprograms first and then all other non-empty units.

The motivation behind this change is the following:
(1) DwarfDebug::beginModule() is run at the very beginning of backend's pipeline,
    from this time IR can be significantly changed by target-specific passes.
    If it happens for debug metadata of global entities, those changes will not
    be reflected in the emitted DWARF.
(2) imported subprogram names should refer to an abstract subprogram if it exists,
    but it isn't known in DwarfDebug::beginModule() (it's possible to make some
    guesses based on location info, but it's not quite reliable);
(3) aforementioned entities if they are scoped within a bracketed block
    (subject of D113741) couldn't be emitted in DwarfDebug::beginModule()
    (they need parent emitted first). Another problem is if to try to gather
    some information about local entities and defer their emission
    (till subprogram's processing or DwarfDebug::endModule()) all the gathered
    details might be irrelevant / invalid by the time the entities are being
    emitted (because of (1)).

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D114705
2021-12-04 14:10:01 +02:00
Sam Clegg 6f5c5cbe5f [lld][WebAssembly] Fix for debug relocations against undefined function symbols
This is very similar to https://reviews.llvm.org/D103557 but applies to
symbols which are undefined at link time rather than compile time.

We already have code that handles symbols which were defined at link
time but dead stripped by `--gc-sections` (See
`test/wasm/debug-removed-fn.ll`). In that case the symbols are not live
(!isLive()).  However, we can also have live symbols (which are
references by the program) but which are undefined at link time and are
imported by the linker.

In the test case here the symbol `undef` is used but is not defined
in the program but is imported by the linker due to the
`--import-undefined` flag.

Fixes: https://github.com/emscripten-core/emscripten/issues/15528

Differential Revision: https://reviews.llvm.org/D114921
2021-12-02 08:36:28 -08:00
David Blaikie 78758026e2 Fix lld test after dwarfdump array syntax change 2021-11-05 23:00:29 -07:00
Sam Clegg 182b72aa48 [lld][WebAssembly] Generate TLS relocation code also when linking statically
Previously relocations were only generated for PIC output, but
relocations for TLS GOT entries are always needed when shared
memory is enabled, not just in PIC mode.

This means that the `__wasm_apply_global_tls_relocs` is now
generated even for statically linked (non-PIC) output.  Without
this the globals that hold the addresses of TLS symbols are
not set correctly.

Differential Revision: https://reviews.llvm.org/D112833
2021-10-29 13:26:35 -07:00
Sam Clegg 1eb79e732c [lld][WebAssembly] Initialize bss segments using memory.fill
Previously we were relying on the dynamic loader to take care of this
but it simple and correct for us to do it here instead.

Now we initialize bss segments as part of `__wasm_init_memory` at the
same time we initialize passive segments.

In addition we extent the us of `__wasm_init_memory` outside of shared
memory situations.  Specifically it is now used to initialize bss
segments when the memory is imported.

Differential Revision: https://reviews.llvm.org/D112667
2021-10-28 17:15:08 -07:00
Sam Clegg 50bfc45109 [lld][WebAssemlby] Always enable mutable-globals feature in PIC mode
This works around an issue where the feature can be forgotten
in the case of LTO + object file with no functions.

See: https://bugs.llvm.org/show_bug.cgi?id=52339

Differential Revision: https://reviews.llvm.org/D112769
2021-10-28 16:24:54 -07:00
Sam Clegg 28848e9e1b [lld][WebAssembly] Handle duplicate archive member names in ThinLTO
This entire change, including the test case, comes almost verbatim
from the ELF driver.

Fixes: https://github.com/emscripten-core/emscripten/issues/12763

Differential Revision: https://reviews.llvm.org/D112723
2021-10-28 11:48:04 -07:00
Sam Clegg 1aeb4c4a43 [lld][WebAssebmly] Convert tests to use disassembly. NFC
Differential Revision: https://reviews.llvm.org/D112590
2021-10-27 10:34:52 -07:00
Paulo Matos 6d0c7bc17d [WebAssembly] Implementation of table.get/set for reftypes in LLVM IR
This change implements new DAG nodes TABLE_GET/TABLE_SET, and lowering
methods for load and stores of reference types from IR arrays. These
global LLVM IR arrays represent tables at the Wasm level.

Differential Revision: https://reviews.llvm.org/D111154
2021-10-20 10:31:31 +02:00
Sam Clegg 659a08399a [WebAssembly] Add import info to `dylink` section of shared libraries
See https://github.com/WebAssembly/tool-conventions/pull/175

Differential Revision: https://reviews.llvm.org/D111345
2021-10-15 11:49:16 -07:00
Heejin Ahn 9261ee32dc [WebAssembly] Make EH work with dynamic linking
This makes Wasm EH work with dynamic linking. So far we were only able
to handle destructors, which do not use any tags or LSDA info.

1. This uses `TargetExternalSymbol` for `GCC_except_tableN` symbols,
   which points to the address of per-function LSDA info. It is more
   convenient to use than `MCSymbol` because it can take additional
   target flags.

2. When lowering `wasm_lsda` intrinsic, if PIC is enabled, make the
   symbol relative to `__memory_base` and generate the `add` node. If
   PIC is disabled, continue to use the absolute address.

3. Make tag symbols (`__cpp_exception` and `__c_longjmp`) undefined in
   the backend, because it is hard to make it work with dynamic
   linking's loading order. Instead, we make all tag symbols undefined
   in the LLVM backend and import it from JS.

4. Add support for undefined tags to the linker.

Companion patches:
- https://github.com/WebAssembly/binaryen/pull/4223
- https://github.com/emscripten-core/emscripten/pull/15266

Reviewed By: sbc100

Differential Revision: https://reviews.llvm.org/D111388
2021-10-12 23:28:27 -07:00
Heejin Ahn 3ec1760d91 [WebAssembly] Remove WasmTagType
This removes `WasmTagType`. `WasmTagType` contained an attribute and a
signature index:
```
struct WasmTagType {
  uint8_t Attribute;
  uint32_t SigIndex;
};
```

Currently the attribute field is not used and reserved for future use,
and always 0. And that this class contains `SigIndex` as its property is
a little weird in the place, because the tag type's signature index is
not an inherent property of a tag but rather a reference to another
section that changes after linking. This makes tag handling in the
linker also weird that tag-related methods are taking both `WasmTagType`
and `WasmSignature` even though `WasmTagType` contains a signature
index. This is because the signature index changes in linking so it
doesn't have any info at this point. This instead moves `SigIndex` to
`struct WasmTag` itself, as we did for `struct WasmFunction` in D111104.

In this CL, in lib/MC and lib/Object, this now treats tag types in the
same way as function types. Also in YAML, this removes `struct Tag`,
because now it only contains the tag index. Also tags set `SigIndex` in
`WasmImport` union, as functions do.

I think this makes things simpler and makes tag handling more in line
with function handling. These two shares similar properties in that both
of them have signatures, but they are kind of nominal so having the same
signature doesn't mean they are the same element.

Also a drive-by fix: the reserved 'attirubute' part's encoding changed
from uleb32 to uint8 a while ago. This was fixed in lib/MC and
lib/Object but not in YAML. This doesn't change object files because the
field's value is always 0 and its encoding is the same for the both
encoding.

This is effectively NFC; I didn't mark it as such just because it
changed YAML test results.

Reviewed By: sbc100, tlively

Differential Revision: https://reviews.llvm.org/D111086
2021-10-05 17:11:22 -07:00
Sam Clegg 8fe128476e [lld][WebAssembly] Create optional internal symbols only after LTO object as been added
This is important for the cases where new symbols can be introduced
during LTO.   Specifically this happens for during TLS-lowering where
references to `__tls_base` can be introduced.

Fixes: https://github.com/emscripten-core/emscripten/issues/12489

Differential Revision: https://reviews.llvm.org/D111171
2021-10-05 13:31:09 -07:00
Thomas Lively 962acf0a27 [lld][WebAssembly] Use llvm-objdump to test __wasm_init_memory
Rather than depending on the hex dump from obj2yaml. Now the test shows the
expected function body in a human readable format.

Differential Revision: https://reviews.llvm.org/D109730
2021-09-14 18:07:59 -07:00
Sam Clegg 6ee55f9ab5 Fix test failure created by ef8c9135ef
Followup to https://reviews.llvm.org/D108877 to fix test
failure.
2021-09-14 07:35:05 -07:00
Sam Clegg ef8c9135ef [WebAssembly] Allow import and export of TLS symbols between DSOs
We previously had a limitation that TLS variables could not
be exported (and therefore could also not be imported).  This
change removed that limitation.

Differential Revision: https://reviews.llvm.org/D108877
2021-09-14 06:47:37 -07:00
Thomas Lively b2032f18c9 [lld][WebAssembly] Relax limitations on multithreaded instantiation
For multithreaded modules (i.e. modules with a shared memory), lld injects a
synthetic Wasm start function that is automatically called during instantiation
to initialize memory from passive data segments. Even though the module will be
instantiated separately on each thread, memory initialization should happen only
once. Furthermore, memory initialization should be finished by the time each
thread finishes instantiation. Since multiple threads may be instantiating their
modules at the same time, the synthetic function must synchronize them.

The current synchronization tries to atomically increment a flag from 0 to 1 in
memory then enters one of two cases. First, if the increment was successful, the
current thread is responsible for initializing memory. It does so, increments
the flag to 2 to signify that memory has been initialized, then notifies all
threads waiting on the flag. Otherwise, the thread atomically waits on the flag
with an expected value of 1 until memory has been initialized. Either the
initializer thread finishes initializing memory (i.e. sets the flag to 2) first
and the waiter threads do not end up blocking, or the waiter threads succesfully
start waiting before memory is initialized so they will be woken by the
initializer thread once it has finished.

One complication with this scheme is that there are various contexts on the Web,
most notably on the main browser thread, that cannot successfully execute a
wait. Executing a wait in these contexts causes a trap, and in this case would
cause instantiation to fail. The embedder must therefore ensure that these
contexts win the race and become responsible for initializing memory, since that
is the only code path that does not execute a wait.

Unfortunately, since only one thread can win the race and initialize memory,
this scheme makes it impossible to have multiple threads in contexts that cannot
wait. For example, it is not currently possible to instantiate the module on
both the main browser thread as well as in an AudioWorklet. To loosen this
restriction, this commit inserts an extra check so that the wait will not be
executed at all when memory has already been initialized, i.e. when the flag
value is 2. After this change, the module can be instantiated on threads in
non-waiting contexts as long as the embedder can guarantee either that the
thread will win the race and initialize memory (as before) or that memory has
already been initialized when instantiation begins. Threads in contexts that can
wait can continue racing to initialize memory.

Fixes (or at least improves) PR51702.

Reviewed By: dschuff

Differential Revision: https://reviews.llvm.org/D109722
2021-09-13 15:03:51 -07:00
Sam Clegg b78c85a44a [WebAssembly] Convert to new "dylink.0" section format
This format is based on sub-sections (like the "linking" and "name"
sections) and is therefore easier to extend going forward.

spec change: https://github.com/WebAssembly/tool-conventions/pull/170
binaryen change: https://github.com/WebAssembly/binaryen/pull/4141
wabt change:  https://github.com/WebAssembly/wabt/pull/1707
emscripten change: https://github.com/emscripten-core/emscripten/pull/15019

Differential Revision: https://reviews.llvm.org/D109595
2021-09-12 05:30:38 -07:00
Sam Clegg 6355234660 [lld][WebAssembly] Fix crash on un-used __tls_base symbol
In the case that TLS is used in the single-threaded program, and
therefore effectively lowered away, we still optionally create a
`__tls_base` symbols, but the code for setting it was assuming it was
always created.

Differential Revision: https://reviews.llvm.org/D109518
2021-09-09 12:45:58 -04:00
David Blaikie bc066e26c9 DebugInfo: Fix a few bot failures for type dumping fixes 2021-09-03 14:08:58 -07:00
Heejin Ahn 77b921b870 [WebAssembly] Tidy up EH/SjLj options
This CL is small, but the description can be a little long because I'm
trying to sum up the status quo for Emscripten/Wasm EH/SjLj options.

First, this CL adds an option for Wasm SjLj (`-wasm-enable-sjlj`), which
handles SjLj using Wasm EH. The implementation for this will be added as
a followup CL, but this adds the option first to do error checking.

This also adds an option for Wasm EH (`-wasm-enable-eh`), which has been
already implemented. Before we used `-exception-model=wasm` as the same
meaning as enabling Wasm EH, but after we add Wasm SjLj, it will be
possible to use Wasm EH instructions for Wasm SjLj while not enabling
EH, so going forward, to use Wasm EH, `opt` and `llc` will need this
option. This only affects `opt` and `llc` command lines and does not
affect Emscripten user interface.

Now we have two modes of EH (Emscripten/Wasm) and also two modes of SjLj
(also Emscripten/Wasm). The options corresponding to each of are:
- Emscripten EH: `-enable-emscripten-cxx-exceptions`
- Emscripten SjLj: `-enable-emscripten-sjlj`
- Wasm EH: `-wasm-enable-eh -exception-model=wasm`
           `-mattr=+exception-handling`
- Wasm SjLj: `-wasm-enable-sjlj -exception-model=wasm`
             `-mattr=+exception-handling`
The reason Wasm EH/SjLj's options are a little complicated are
`-exception-model` and `-mattr` are common LLVM options ane not under
our control. (`-mattr` can be omitted if it is embedded within the
bitcode file.)

And we have the following rules of the option composition:
- Emscripten EH and Wasm EH cannot be turned on at the same itme
- Emscripten SjLj and Wasm SjLj cannot be turned on at the same time
- Wasm SjLj should be used with Wasm EH

Which means we now allow these combinations:
- Emscripten EH + Emscripten SjLj: the current default in `emcc`
- Wasm EH + Emscripten SjLj:
  This is allowed, but only as an interim step in which we are testing
  Wasm EH but not yet have a working implementation of Wasm SjLj. This
  will error out (D107687) in compile time if `setjmp` is called in a
  function in which Wasm exception is used.
- Wasm EH + Wasm SjLj:
  This will be the default mode later when using Wasm EH. Currently Wasm
  SjLj implementation doesn't exist, so it doesn't work.
- Emscripten EH + Wasm SjLj will not work.

This CL moves these error checking routines to
`WebAssemblyPassConfig::addIRPasses`. Not sure if this is an ideal place
to do this, but I couldn't find elsewhere. Currently some checking is
done within LowerEmscriptenEHSjLj, but these checks only run if
LowerEmscriptenEHSjLj runs so it may not run when Wasm EH is used. This
moves that to `addIRPasses` and adds some more checks.

Currently LowerEmscriptenEHSjLj pass is responsible for Emscripten EH
and Emscripten SjLj. Wasm EH transformations are done in multiple
places, including WasmEHPrepare, LateEHPrepare, and CFGStackify. But in
the followup CL, LowerEmscriptenEHSjLj pass will be also responsible for
a part of Wasm SjLj transformation, because WasmSjLj will also be using
several Emscripten library functions, and we will be sharing more than
half of the transformation to do that between Emscripten SjLj and Wasm
SjLj.

Currently we have `-enable-emscripten-cxx-exceptions` and
`-enable-emscripten-sjlj` but these only work for `llc`, because for
`llc` we feed these options to the pass but when we run the pass using
`opt` the pass will be created with no options and the default options
will be used, which turns both Emscripten EH and Emscripten SjLj on.

Now we have one more SjLj option to care for, LowerEmscriptenEHSjLj pass
needs a finer way to control these options. This CL removes those
default parameters and make LowerEmscriptenEHSjLj pass read directly
from command line options specified. So if we only run
`opt -wasm-lower-em-ehsjlj`, currently both Emscripten EH and Emscripten
SjLj will run, but with this CL, none will run unless we additionally
pass `-enable-emscripten-cxx-exceptions` or `-enable-emscripten-sjlj`,
or both. This does not affect users; this only affects our `opt` tests
because `emcc` will not call either `opt` or `llc`. As a result of this,
our existing Emscripten EH/SjLj tests gained one or both of those
options in their `RUN` lines.

Reviewed By: dschuff

Differential Revision: https://reviews.llvm.org/D107685
2021-08-24 17:54:39 -07:00
Sam Clegg c468dc1b12 [lld][WebAssembly] Handle weakly defined symbols in shared libraries.
In the case of weakly defined symbols in shared libraries we now
generate both an import and an export.  The dynamic linker can then
choose how a winner from among all the shared libraries that define a
given symbol.

Previously any direct usage of a weakly defined symbol would use the
DSO-local definition (For example, even through there would be single
address for a weakly defined function, each DSO could end up directly
calling its local version).

Fixes: https://github.com/emscripten-core/emscripten/issues/13773

Differential Revision: https://reviews.llvm.org/D108413
2021-08-19 19:25:49 -04:00
Sam Clegg e4888be74e [WebAssembly] Avoid unused function imports in PIC mode
In PIC mode we import function address via `GOT.mem` imports but for
direct function calls we still import the first class function.
However, if the function is never directly called we can avoid the first
class import completely.

Differential Revision: https://reviews.llvm.org/D108345
2021-08-18 22:31:04 -04:00
Sam Clegg 12b1dc0467 [WebAssembly][lld] Convert signature-mismatch.ll test to asm. NFC
Differential Revision: https://reviews.llvm.org/D108346
2021-08-18 22:17:02 -04:00
Sam Clegg 56175b2f5c [lld][WebAssembly] Prefer objdump -d over obj2yaml for tests. NFC
Now that we have https://reviews.llvm.org/D105539 we can
use objdump -d to actually check for instruction sequences
rather than binary blobs.

This is just an example of how to do that we should followup
with a wider ranging conversion of existing tests.

Differential Revision: https://reviews.llvm.org/D106897
2021-08-10 18:17:58 -04:00
Derek Schuff cf54424a46 [lld][WebAssembly] Do not remove name section with --strip-debug
Leave the name section in the output when using the --strip-debug
flag. This treats it more like ELF symbol tables, as the name
section has similar uses at runtime (e.g. wasm engines understand
it and it can be used for symbolization at runtime).

Fixes https://github.com/emscripten-core/emscripten/issues/14623

Differential Revision: https://reviews.llvm.org/D106728
2021-07-26 11:06:52 -07:00
Ayke van Laethem 13ca0c87ed
[lld][WebAssembly] Align __heap_base
__heap_base was not aligned. In practice, it will often be aligned
simply because it follows the stack, but when the stack is placed at the
beginning (with the --stack-first option), the __heap_base might be
unaligned. It could even be byte-aligned.

At least wasi-libc appears to expect that __heap_base is aligned:
659ff41456/dlmalloc/src/malloc.c (L5224)

While WebAssembly itself does not appear to require any alignment for
memory accesses, it is sometimes required when sharing a pointer
externally. For example, WASI might expect alignment up to 8:
https://github.com/WebAssembly/WASI/blob/main/phases/snapshot/docs.md#-timestamp-u64

This issue got introduced with the addition of the --stack-first flag:
https://reviews.llvm.org/D46141
I suspect the lack of alignment wasn't intentional here.

Differential Revision: https://reviews.llvm.org/D106499
2021-07-24 14:03:26 +02:00
Nick Fitzgerald 1d445a6e76 Reland: "[WebAssembly] Deduplicate imports of the same module name, field name, and type"
When two symbols import the same thing, only one import should be
emitted in the Wasm file.

Fixes https://bugs.llvm.org/show_bug.cgi?id=50938

Reverted in: 16aac493e5.

Reviewed By: sbc100

Differential Revision: https://reviews.llvm.org/D105519
2021-07-22 14:16:05 -07:00
Sam Clegg d51f74acdf [lld][WebAssembly] Error on import of TLS symbols in shared libraries
In https://reviews.llvm.org/D102044 we made exporting a TLS symbol
into an error, but we also want to error on import.

See https://github.com/emscripten-core/emscripten/issues/14461

Differential Revision: https://reviews.llvm.org/D106385
2021-07-20 12:36:03 -07:00
Fangrui Song 16aac493e5 Revert D105519 "[WebAssembly] Deduplicate imports of the same module name, field name, and type" and its followup
This reverts commit 4ae575b999 and 9b965b37c7.

There is an use-of-uninitialized-value bug in the `else` branch in ImportSection::addImport.
2021-07-19 17:09:01 -07:00
Derek Schuff ad1f5457d2 [WebAssembly] Generate R_WASM_FUNCTION_OFFSET relocs in debuginfo sections
Debug info sections need R_WASM_FUNCTION_OFFSET_I32 relocs (with FK_Data_4 fixup
kinds) to refer to functions (instead of R_WASM_TABLE_INDEX as is used in data
sections). Usually this is done in a convoluted way, with unnamed temp data
symbols which target the start of the function, in which case
WasmObjectWriter::recordRelocation converts it to use the section symbol
instead. However in some cases the function can actually be undefined; in this
case the dwarf generator uses the function symbol (a named undefined function
symbol) instead. In that case the section-symbol transform doesn't work and we
need to generate the correct reloc type a different way. In this change
WebAssemblyWasmObjectWriter::getRelocType takes the fixup section type into
account to choose the correct reloc type.

Fixes PR50408
Differential Revision: https://reviews.llvm.org/D103557
2021-07-19 14:02:33 -07:00
Nick Fitzgerald 4ae575b999 [WebAssembly] Deduplicate imports of the same module name, field name, and type
When two symbols import the same thing, only one import should be emitted in the Wasm file.

Fixes https://bugs.llvm.org/show_bug.cgi?id=50938

Reviewed By: sbc100

Differential Revision: https://reviews.llvm.org/D105519
2021-07-19 13:59:02 -07:00