2807: Run Wasm code on a separate stack r=Amanieu a=Amanieu
This uses the [corosensei](https://crates.io/crates/corosensei) crate to
run Wasm code on a separate stack from the main thread stack.
In trap handlers for stack overflows and memory out of bounds accesses,
we can now check whether we are executing on the Wasm stack and reset
execution back to the main thread stack when returning from the trap
handler.
When Wasm code needs to perform an operation which may modify internal
data structures (e.g. growing a memory) then execution must switch back
to the main thread stack using on_host_stack. This is necessary to avoid
leaving internal data structure in an inconsistent state when a stack
overflow happens.
In the future, this can also be used to suspend execution of a Wasm
module (#1127) by modeling it as an async function call.
Fixes#2757Fixes#2562
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
This uses the [corosensei](https://crates.io/crates/corosensei) crate to
run Wasm code on a separate stack from the main thread stack.
In trap handlers for stack overflows and memory out of bounds accesses,
we can now check whether we are executing on the Wasm stack and reset
execution back to the main thread stack when returning from the trap
handler.
When Wasm code needs to perform an operation which may modify internal
data structures (e.g. growing a memory) then execution must switch back
to the main thread stack using on_host_stack. This is necessary to avoid
leaving internal data structure in an inconsistent state when a stack
overflow happens.
In the future, this can also be used to suspend execution of a Wasm
module (#1127) by modeling it as an async function call.
Fixes#2757Fixes#2562
The field ordering here is actually significant because of the drop
order: we want to drop the artifact before dropping the engine.
The reason for this is that dropping the Artifact will de-register the
trap handling metadata from the global registry. This must be done before
the code memory for the artifact is freed (which happens when the store
is dropped) since there is a chance that this memory could be reused by
another module which will try to register its own trap information.
Note that in Rust, the drop order for struct fields is from top to
bottom: the opposite of C++.
In the future, this code should be refactored to properly describe the
ownership of the code and its metadata.
Fixes#2434
2728: Replace RuntimeError::raise with RuntimeError::custom r=syrusakbary a=Amanieu
`RuntimeError::raise` should not be exposed to user code since it perfoms a `longjmp` internally which is unsound if there are any destructors on the stack. Instead a custom error type should be returned using `RuntimeError::custom` which can be passed through WASM code and later retrieved using `RuntimeError::downcast`.
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
2693: Add extra validation to compilers & engines r=ptitSeb a=Amanieu
- Cranelift and singlepass now properly cross-compile with no dependency on the host target.
- Staticlib engine now panics if you try to run a freshly compiled module.
- CPU features used when a module was compiled are now checked against the host CPU features during instantiation.
Fixes#1567Fixes#2590
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
This allows the contents of an existing namespace to be added to by
extracting an `Exports` from it, adding to that `Exports` and then
replacing the existing namespace with the modified `Exports`.
