Host functions use `Context::External` with a `*mut vm::FuncCtx`
pointer, casted to `*mut vm::Ctx`. It creates a conflict with exports
that also use `Context::External`.
This patch introduces `Context::ExternalWithEnv` to create a specific
path in the code for an external context with `*mut vm::FuncEnv`.
This patch fixes all the `linking.wast` tests in the spectests.
In the `wrap` functions, we use `std::mem::transmute(&())` to get the
pointer to the value “around” `wrap` (`Fn` has a method `to_raw` which
declares a `wrap` function, which uses `transmute` to retrieve
`Fn`). This is an undefined behavior. It was working until the
`FuncCtx` is introduced. Since then, the undefined behavior was
causing an error with the Singlepass backend.
This patch stores the pointer to `Fn` in `func_env`, so that the
pointer to the user-defined host function is always predictable.
929: Update __wasi_rights_t and __wasi_signal_t with published changes r=MarkMcCaskey a=MarkMcCaskey
Follow up to #926 ; fixes everything else listed at https://github.com/WebAssembly/WASI/pull/135
Co-authored-by: Mark McCaskey <mark@wasmer.io>
921: Apply TBAA metadata in the LLVM backend. r=nlewycky a=nlewycky
# Description
Inform LLVM that the pointers to memory, globals, locals, etc., are distinct.
# Review
- [x] Add a short description of the the change to the CHANGELOG.md file
Co-authored-by: Nick Lewycky <nick@wasmer.io>
Co-authored-by: nlewycky <nick@wasmer.io>
911: Don't emit bounds checks when the offset is known at compile time to be less than the minimum memory size. r=nlewycky a=nlewycky
Co-authored-by: Nick Lewycky <nick@wasmer.io>
917: feat(runtime-core) Host function without a `vm::Ctx` argument r=Hywan a=Hywan
Extracted from https://github.com/wasmerio/wasmer/pull/882.
~Includes https://github.com/wasmerio/wasmer/pull/916. Must not be merged until #916 lands in `master`.~
~If you want to compare only the different commits, see https://github.com/Hywan/wasmer/compare/feat-runtime-core-tests...Hywan:feat-runtime-core-host-function-without-vmctx?expand=1.~
This patch updates the `ExternalFunction` implementation to support host functions (aka imported functions) without having an explicit `vm::Ctx` argument.
It is thus possible to write:
```rust
fn add_one(x: i32) -> i32 {
x + 1
}
let import_object = imports! {
"env" => {
"add_one" => func!(add_one);
},
};
```
The previous form is still working though:
```rust
fn add_one(_: &mut vm::Ctx, x: i32) -> i32 {
x + 1
}
```
The backends aren't modified. It means that the pointer to `vm::Ctx` is still inserted in the stack, but it is not used when the function doesn't need it.
We thought this is an acceptable trade-off.
About the C API. It has not check to ensure the type signature. Since the pointer to `vm::Ctx` is always inserted, the C API can digest host functions with or without a `vm::Ctx` argument. The C API uses [the `Export` + `FuncPointer` API](cf5b3cc09e/lib/runtime-c-api/src/import/mod.rs (L630-L653)) instead of going through the `Func` API (which is modified by this API), which is only possible since the C API only receives an opaque function pointer. Conclusion is: We can't ensure anything on the C side, but it will work with or without the `vm::Ctx` argument in theory.
Co-authored-by: Ivan Enderlin <ivan.enderlin@hoa-project.net>
