Following up on the change made in #14611, this change forces the
`WasmOffsetConverter` before calling `receiveInstantiationResult` in both
code paths (instantiateArrayBuffer and instantiateAsync).
With that done (along with #14755) there are no more valid use cases for
to block execution based on the absence of `WasmOffsetConverter`. By
the time the instance is received it is always defined.
This makes them more readable/portable and avoids the need for
`REPORT_RESULT` macro.
As a followup I hope to convert all browser tests but this is major
step in that direction.
I was going to simply move these test to run only on node but in
doing so I noticed some subtle differences in the worker semantics
that effected the offset coverter so I decided its best to run
these in both environments.
However, debugging and maintaining the test is way simpler under
node since we are far better setup to test for stdout/stderr there
This adds three tests for mixing exceptions and sjlj. We currently pass
`test_exceptions_longjmp1`, and other two tests will pass after
c285a11efd.
- `test_exceptions_longjmp1`
In a function with a `setjmp` call, `invoke` exists in LLVM IR. We
have to check both for EH and sjlj when a function throws.
- `test_exceptions_longjmp2`
In a function without a `setjmp` call, `invoke` exists in LLVM IR. We
only have to handle exceptions, but when longjmps occur, we shouldn't
swallow them.
- `test_exceptions_longjmp3`
In a function with a `setjmp` call, there's no `invoke` in LLVM IR. We
only have to handle longjmps, but w hen an exceptions occcur, we
shouldn't swallow them.
Each of these tests corresponds with tests in
test/CodeGen/WebAssembly/lower-em-sjlj.ll in
c285a11efd.
I tried to fix this in #13236 but I don't think it was ever working
correctly. In `MODULARIZE` mode `wasmOffsetConverter` was not being
defined within the module itself (where it is used). his change moves
the construction of `wasmOffsetConverter` and `wasmSourceMap` so they
always occur inside the module.
I've also improved the testing of `wasmOffsetConverter` so we actually
verify that it works in `tests/core/test_return_address.c`.
As described in #14705, errno codes may be looked up dynamically when
using nodefs, noderawfs and proxyfs, but closure was mangling the properties,
making some fs operations behave unexpectedly resulting in undefined behavior.
This quotes those names so closure leaves them as is.
Closes#14705
Adds an easy way to declare asynchronous JS functions. With this helper, users can use await directly inside of such snippets, don't need to wrap every such function into Asyncify.handleAsync manually, don't need to deal with propagating return values, and, finally, don't need to manually list all such functions in ASYNCIFY_IMPORTS since we know statically they're asynchronous.
I've also updated docs to merge "returning values" section into the first example, since it's now straightforward with EM_ASYNC_JS, a bit more involved but still easy with EM_JS + Asyncify.handleAsync, and only Asyncify.handleSleep API requires more explanation.
Fixes#9709.
This method will immediately throw a value, meaning there is no way for it to return to Wasm.
Optimisations aside, adding this attribute allows to use `val.throw_()` in C++ without compiler complaining about `non-void function does not return a value in all control paths [-Wreturn-type]`.
This is rather an odd feature and I think we should notify users if they
are relying on it. Honestly I doubt many are.
See #14689 for an example of how confusing it can be when it goes wrong.
Also, make sure we strip off the full suffix in the case of `.so.1.2.3`
suffixes.
The killed thread was not being correcltly removed from PThread.pthreads
so terminateAllThreads (which only happens when the runtime exists) was
crashing.
By re-syncing lsan_common_emscripten.cpp with lsan_common.cpp,
except for the guard page skip logic (IsAccessibleMemoryRange
always returns true on Emscripten).
This avoids the nasty JS syntax for adjusting the names of the
functions and paves the way for all/part of the code to be
moved to native. This also helps with the pending musl upgrade.
This relies on exporting TLS symbols which we currently do not support.
By default we disable SUPPORT_LONGJMP in this configuration. If the
user tries to explicitly enable it we error out.
See #14461
https://github.com/llvm/llvm-project/commit/db7efcab7dd9 updated the
wasm_*_extract_lane intrinsics to be functions instead of macros, which means
their arguments must now be v128_t rather than any other 128-bit vector type
under -fno-lax-vector-conversions. Update the SIMD compat headers with more
casts to keep them compiling cleanly.
Previously, undefined data symbols we ignored by the linker due to the
use of `--allow-undefined` which causes undefined functions to be
imports but give all undefined data symbols address zero. Sadly there
is no way to turn data symbol references into imports like there is for
functions (due to the way codegen works for static binaries).
The new `--import-undefined` works the same for function but errors
out on undefined data symbols.
Users that want the previous behavior which is to give all undefined
data symbols address zero (like an weak undefined symbol) can use
with `-Wl,--allow-undefined` or `-Wl,--unresolved-symbols=ignore-all`.
Fixes: #14106
This does similar things to what we already do for memcpy etc.,
doing word-sized operations where possible.
On artificial benchmarks this is up to 3.7x faster. This is motivated
by a real-world benchmark where memcmp is very high in the profile.
For consistency, also apply EMSCRIPTEN_OPTIMIZE_FOR_OZ as we
do for memcpy etc., to not unroll loops in clang in that case.
This PR addresses #12367 (cc @vadimkantorov @junjihashimoto @sbc100):
* Use vadimkantorov's patch to library_proxyfs.js (thanks!)
* To prevent this from happening in the future, I added an additional test to make
sure we can get the correct file size of a file mounted on a PROXYFS filesystem
Tests
The additional tests calculates the file size of the file /working2/hoge.txt, which is 6 bytes, but currently returns 0. Note: working2/ is the folder that mounts the filesystem of module 2.
Before the patch:
$ tests/runner --verbose other.test_proxyfs
[...]
parent m0 writes and reads children's files.:m0 read m0:test0_0
test seek.:file size:0
After the patch:
$ tests/runner --verbose other.test_proxyfs
[...]
parent m0 writes and reads children's files.:m0 read m0:test0_0
test seek.:file size:6
Asyncify enables DYNCALLS, and closure + DYNCALLS regressed
in #12046 which removed the closure externs for them. This restores the
externs only in DYNCALLS mode at least, which avoids it affecting the
normal mode.
Fixes#13858
The C version of this function in library_pthread.c was identical to the
musl version except the musl version allows values of <=2 as opposed to
<=1. This difference doesn't appear to be material or intentional.
The custom C version seems to have been ported from the original JS
version back in 64088da3a3.
Also, avoid passing `-flto` more than once to the compiler.
ThinLTO is still pretty much untested, both here, and upstream. This
change doesn't effect that but does fix a real issue.
Fixes: #14694
* Asyncify Embind exports
Previously, if Embind function called an async function via Asyncify
somewhere in its call stack, it would return garbage default value
(`0` / `false` / class instance with a `NULL` pointer / etc.).
This PR changes such exports to instead return Promises when they
invoke an async function, and direct values otherwise. This preserves
backward compatibility for synchronous exports, while providing a more
useful value for async use-cases.
If Asyncify imports are invoked dynamically and user isn't sure which
exports will end up being async or not, they can simply use `await`
on all Embind exports and it will do the right thing as it works
correctly with both Promises and synchronous values alike.
Fixes#11890.
Sam Clegg
かめのこにょこにょこ
Ingvar Stepanyan
Heejin Ahn
Cynthia
Kleis Auke Wolthuizen
Alon Zakai
Thomas Lively
Robert Aboukhalil
Rafael Brune