[lld][WebAssembly] Fix crash on undefined+weak function syms in LTO objects

Symbols from LTO objects don't contain Wasm signatures, but we need a
signature when we create undefined/stub functions fo

[lld][WebAssembly] Fix crash on undefined+weak function syms in LTO objects

Symbols from LTO objects don't contain Wasm signatures, but we need a
signature when we create undefined/stub functions for missing weakly
undefined symbols.

Luckily, after LTO, we know that symbols that are not referenced by a
regular object file must not be needed in the final output so there
is no need to generate undefined/stub function for them.

Differential Revision: https://reviews.llvm.org/D126554

show more ...

Re-land [LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers wi

Re-land [LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inherit from this structure and add their own global state, in the same way as for the existing COFFLinkerContext.

See discussion in https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html

The previous land f860fe362282ed69b9d4503a20e5d20b9a041189 caused issues in https://lab.llvm.org/buildbot/#/builders/123/builds/8383, fixed by 22ee510dac9440a74b2e5b3fe3ff13ccdbf55af3.

Differential Revision: https://reviews.llvm.org/D108850

show more ...

Revert [LLD] Remove global state in lldCommon

It seems to be causing issues on https://lab.llvm.org/buildbot/#/builders/123/builds/8383

[LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inher

[LLD] Remove global state in lldCommon

Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inherit from this structure and add their own global state, in the same way as for the existing COFFLinkerContext.

See discussion in https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html

Differential Revision: https://reviews.llvm.org/D108850

show more ...

[lld] Rename addCombinedLTOObjects to match ELF driver. NFC

This function was renamed in https://reviews.llvm.org/D62291.
The new name seems more accurate and also its good to maintain
some consiste

[lld] Rename addCombinedLTOObjects to match ELF driver. NFC

This function was renamed in https://reviews.llvm.org/D62291.
The new name seems more accurate and also its good to maintain
some consistency between these methods in the different drivers.

Differential Revision: https://reviews.llvm.org/D112719

show more ...

fix comment typos to cycle bots

[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 `T

[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

show more ...

[WebAssembly] Remove WasmTagType

This removes `WasmTagType`. `WasmTagType` contained an attribute and a
signature index:
```
struct WasmTagType {
uint8_t Attribute;
uint32_t SigIndex;
};
```

Cu

[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

show more ...

[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 fo

[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

show more ...

[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,

[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

show more ...

[WebAssembly] Rename event to tag

We recently decided to change 'event' to 'tag', and 'event section' to
'tag section', out of the rationale that the section contains a
generalized tag that referenc

[WebAssembly] Rename event to tag

We recently decided to change 'event' to 'tag', and 'event section' to
'tag section', out of the rationale that the section contains a
generalized tag that references a type, which may be used for something
other than exceptions, and the name 'event' can be confusing in the web
context.

See
- https://github.com/WebAssembly/exception-handling/issues/159#issuecomment-857910130
- https://github.com/WebAssembly/exception-handling/pull/161

Reviewed By: tlively

Differential Revision: https://reviews.llvm.org/D104423

show more ...

[lld][WebAssembly] Refactor input chunk class hierarchy. NFC

The main motivation for this refactor is to remove the subclass
relationship between the InputSegment and MergeInputSegment and
Syntentic

[lld][WebAssembly] Refactor input chunk class hierarchy. NFC

The main motivation for this refactor is to remove the subclass
relationship between the InputSegment and MergeInputSegment and
SyntenticMergedInputSegment so that we can use the merging classes for
debug sections which are not data segments.

In the process of refactoring I also remove all the virtual functions
from the class hierarchy and try to reuse techniques used in the ELF
linker (see `lld/ELF/InputSections.h`).

Differential Revision: https://reviews.llvm.org/D102546

show more ...

[lld][WebAssembly] -Bsymbolic creates indirect function table if needed

It can be that while processing relocations, we realize that in the end
we need an indirect function table. Ensure that one i

[lld][WebAssembly] -Bsymbolic creates indirect function table if needed

It can be that while processing relocations, we realize that in the end
we need an indirect function table. Ensure that one is present, in that
case, to avoid writing invalid object files.

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

Differential Revision: https://reviews.llvm.org/D97843

show more ...

[lld][WebAssembly] Rename methods/members to match ELF backend. NFC.

Specifically:

- InputChunk::outputOffset -> outSecOffset
- Symbol::get/setVirtualAddress -> get/setVA
- add InputChunk::getOffse

[lld][WebAssembly] Rename methods/members to match ELF backend. NFC.

Specifically:

- InputChunk::outputOffset -> outSecOffset
- Symbol::get/setVirtualAddress -> get/setVA
- add InputChunk::getOffset helper that takes an offset

These are mostly in preparation for adding support for
SHF_MERGE/SHF_STRINGS but its also good to align with ELF where
possible.

Differential Revision: https://reviews.llvm.org/D97595

show more ...

[lld][WebAssembly] Common superclass for input globals/events/tables

This commit regroups commonalities among InputGlobal, InputEvent, and
InputTable into the new InputElement. The subclasses are d

[lld][WebAssembly] Common superclass for input globals/events/tables

This commit regroups commonalities among InputGlobal, InputEvent, and
InputTable into the new InputElement. The subclasses are defined
inline in the new InputElement.h. NFC.

Reviewed By: sbc100

Differential Revision: https://reviews.llvm.org/D94677

show more ...

[lld][WebAssembly] Fix typo in function name

addOptionalGlobalSymbols should be addOptionalGlobalSymbol.

Also, remove unnecessary additional argument to make the signature match
the sibling functio

[lld][WebAssembly] Fix typo in function name

addOptionalGlobalSymbols should be addOptionalGlobalSymbol.

Also, remove unnecessary additional argument to make the signature match
the sibling function: addOptionalDataSymbol.

Differential Revision: https://reviews.llvm.org/D96305

show more ...

[WebAssembly] Add support for table linking to wasm-ld

This patch adds support to wasm-ld for linking multiple table references
together, in a manner similar to wasm globals. The indirect function
t

[WebAssembly] Add support for table linking to wasm-ld

This patch adds support to wasm-ld for linking multiple table references
together, in a manner similar to wasm globals. The indirect function
table is synthesized as needed.

To manage the transitional period in which the compiler doesn't yet
produce TABLE_NUMBER relocations and doesn't residualize table symbols,
the linker will detect object files which have table imports or
definitions, but no table symbols. In that case it will synthesize
symbols for the defined and imported tables.

As a change, relocatable objects are now written with table symbols,
which can cause symbol renumbering in some of the tests. If no object
file requires an indirect function table, none will be written to the
file. Note that for legacy ObjFile inputs, this test is conservative: as
we don't have relocs for each use of the indirecy function table, we
just assume that any incoming indirect function table should be
propagated to the output.

Differential Revision: https://reviews.llvm.org/D91870

show more ...

Revert "[WebAssembly] Add support for table linking to wasm-ld"

This reverts commit 38dfce706f796dc109ea495dd69a8cb4c8fa819d.
CI discovered a bug where the table is exported twice: see
D91870

[WebAssembly] Add support for table linking to wasm-ld

This patch adds support to wasm-ld for linking multiple table references
together, in a manner similar to wasm globals. The indirect function
t

[WebAssembly] Add support for table linking to wasm-ld

This patch adds support to wasm-ld for linking multiple table references
together, in a manner similar to wasm globals. The indirect function
table is synthesized as needed.

To manage the transitional period in which the compiler doesn't yet
produce TABLE_NUMBER relocations and doesn't residualize table symbols,
the linker will detect object files which have table imports or
definitions, but no table symbols. In that case it will synthesize
symbols for the defined and imported tables.

As a change, relocatable objects are now written with table symbols,
which can cause symbol renumbering in some of the tests. If no object
file requires an indirect function table, none will be written to the
file. Note that for legacy ObjFile inputs, this test is conservative: as
we don't have relocs for each use of the indirecy function table, we
just assume that any incoming indirect function table should be
propagated to the output.

Differential Revision: https://reviews.llvm.org/D91870

show more ...

[lld][WebAssembly] Add support for handling table symbols

This commit adds table symbol support in a partial way, while still
including some special cases for the __indirect_function_table symbol.
N

[lld][WebAssembly] Add support for handling table symbols

This commit adds table symbol support in a partial way, while still
including some special cases for the __indirect_function_table symbol.
No change in tests.

Differential Revision: https://reviews.llvm.org/D94075

show more ...

[lld][WebAssembly] Ensure stub symbols always get address 0

Without this extra flag we can't distingish between stub functions and
functions that happen to have address 0 (relative to __table_base).

[lld][WebAssembly] Ensure stub symbols always get address 0

Without this extra flag we can't distingish between stub functions and
functions that happen to have address 0 (relative to __table_base).

Adding this flag bit the base symbol class actually avoids growing the
SymbolUnion struct which would not be true if we added it to the
FunctionSymbol subclass (due to bitbacking).

The previous approach of setting it's table index to zero worked for
normal static relocations but not for `-fPIC` code.

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

Differential Revision: https://reviews.llvm.org/D92038

show more ...

[lld][WebAssembly] Implement --unresolved-symbols

This is a more full featured version of ``--allow-undefined``.
The semantics of the different methods are as follows:

report-all:

Report all un

[lld][WebAssembly] Implement --unresolved-symbols

This is a more full featured version of ``--allow-undefined``.
The semantics of the different methods are as follows:

report-all:

Report all unresolved symbols. This is the default. Normally the
linker will generate an error message for each reported unresolved
symbol but the option ``--warn-unresolved-symbols`` can change this
to a warning.

ignore-all:

Resolve all undefined symbols to zero. For data and function
addresses this is trivial. For direct function calls, the linker
will generate a trapping stub function in place of the undefined
function.

import-functions:

Generate WebAssembly imports for any undefined functions. Undefined
data symbols are resolved to zero as in `ignore-all`. This
corresponds to the legacy ``--allow-undefined`` flag.

The plan is to followup with a new mode called `import-dynamic` which
allows for statically linked binaries to refer to both data and
functions symbols from the embedder.

Differential Revision: https://reviews.llvm.org/D79248

show more ...

[lld][WebAssembly] Allow references to __tls_base without shared memory

Previously we limited the use of atomics and TLS to programs
linked with `--shared-memory`.

However, as of https://reviews.ll

[lld][WebAssembly] Allow references to __tls_base without shared memory

Previously we limited the use of atomics and TLS to programs
linked with `--shared-memory`.

However, as of https://reviews.llvm.org/D79530 we now allow
programs that use atomic to be linked without `--shared-memory`.
For this to be useful we also want to all TLS usage in such
programs. In this case, since we know we are single threaded
we simply include the TLS data as a regular active segment
and create an immutable `__tls_base` global that point to the
start of this segment.

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

Differential Revision: https://reviews.llvm.org/D91115

show more ...

[WebAssembly] wasm64: fix memory.init operand types

I had assumed they would all become in i64, but this is not necessary as long as data segments stay 32-bit, see:
https://github.com/WebAssembly/me

[WebAssembly] wasm64: fix memory.init operand types

I had assumed they would all become in i64, but this is not necessary as long as data segments stay 32-bit, see:
https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md

Differential Revision: https://reviews.llvm.org/D85552

show more ...

[lld][WebAssembly] Handle weakly referenced symbols when lazy (archive) version is see first

When a weak reference of a lazy symbol occurs we were not correctly
updating the lazy symbol. We need to

[lld][WebAssembly] Handle weakly referenced symbols when lazy (archive) version is see first

When a weak reference of a lazy symbol occurs we were not correctly
updating the lazy symbol. We need to tag the existing lazy symbol
as weak and, in the case of a function symbol, give it a signature.

Without the signature we can't then create the dummy function which
is needed when an weakly undefined function is called.

We had tests for weakly referenced lazy symbols but we were only
tests in the case where the reference was seen before the lazy
symbol.

See: https://github.com/WebAssembly/wasi-libc/pull/214

Differential Revision: https://reviews.llvm.org/D85567

show more ...