This commit deletes the old `snapshot_0` implementation of wasi-common,
along with the `wig` crate that was used to generate bindings for it.
This then reimplements `snapshot_0` in terms of
`wasi_snapshot_preview1`. There were very few changes between the two
snapshots:
* The `nlink` field of `FileStat` was increased from 32 to 64 bits.
* The `set` field of `whence` was reordered.
* Clock subscriptions in polling dropped their redundant userdata field.
This makes all of the syscalls relatively straightforward to simply
delegate to the next snapshot's implementation. Some trickery happens to
avoid extra cost when dealing with iovecs, but since the memory layout
of iovecs remained the same this should still work.
Now that `snapshot_0` is using wiggle we simply have a trait to
implement, and that's implemented for the same `WasiCtx` that has the
`wasi_snapshot_preview1` trait implemented for it as well. While this
theoretically means that you could share the file descriptor table
between the two snapshots that's not supported in the generated bindings
just yet. A separate `WasiCtx` will be created for each WASI module.
* Enhance wiggle to generate its UserErrorConverstion trait with a function that returns
a Result<abi_err, String>. This enhancement allows hostcall implementations using wiggle
to return an actionable error to the instance (the abi_err) or to terminate the instance
using the String as fatal error information.
* Enhance wiggle to generate its UserErrorConverstion trait with a function that returns
a Result<abi_err, String>. This enhancement allows hostcall implementations using wiggle
to return an actionable error to the instance (the abi_err) or to terminate the instance
using the String as fatal error information.
* Enhance the wiggle/wasmtime integration to leverage new work in ab7e9c6. Hostcall
implementations generated by wiggle now return an Result<abi_error, Trap>. As a
result, hostcalls experiencing fatal errors may trap, thereby terminating the
wasmtime instance. This enhancement has been performed for both wasi snapshot1
and wasi snapshot0.
* Update wasi-nn crate to reflect enhancement in issue #2418.
* Update wiggle test-helpers for wiggle enhancement made in issue #2418.
* Address PR feedback; omit verbose return statement.
* Address PR feedback; manually format within a proc macro.
* Address PR feedback; manually format proc macro.
* Restore return statements to wasi.rs.
* Restore return statements in funcs.rs.
* Address PR feedback; omit TODO and fix formatting.
* Ok-wrap error type in assert statement.
With the module linking proposal the field name on imports is now
optional, and only the module is required to be specified. This commit
propagates this API change to the boundary of wasmtime's API, ensuring
consumers are aware of what's optional with module linking and what
isn't. Note that it's expected that all existing users will either
update accordingly or unwrap the result since module linking is
presumably disabled.
If a host-defined `Func::new` closure returns values from the wrong
store, this currently trips a debug assertion and causes other issues
elsewhere in release mode. This commit adds the same dynamic checks
found in `Func::wrap` in the `Func::new` case today.
This fixes an issue where if a store-incompatible value is returned from
a host-defined function then that value is leaked. Practically this
means that it's possible to accidentally leak `Func` values, but a
simple insertion of a `drop` does the trick!
* Add an initial wasi-nn implementation for Wasmtime
This change adds a crate, `wasmtime-wasi-nn`, that uses `wiggle` to expose the current state of the wasi-nn API and `openvino` to implement the exposed functions. It includes an end-to-end test demonstrating how to do classification using wasi-nn:
- `crates/wasi-nn/tests/classification-example` contains Rust code that is compiled to the `wasm32-wasi` target and run with a Wasmtime embedding that exposes the wasi-nn calls
- the example uses Rust bindings for wasi-nn contained in `crates/wasi-nn/tests/wasi-nn-rust-bindings`; this crate contains code generated by `witx-bindgen` and eventually should be its own standalone crate
* Test wasi-nn as a CI step
This change adds:
- a GitHub action for installing OpenVINO
- a script, `ci/run-wasi-nn-example.sh`, to run the classification example
This commit fixes an issue with wasmtime where it was possible for a
trampoline from one module to get used for another module after it was
freed. This issue arises because we register a module's native
trampolines *before* it's fully instantiated, which is a fallible
process. Some fallibility is predictable, such as import type
mismatches, but other fallibility is less predictable, such as failure
to allocate a linear memory.
The problem happened when a module was registered with a `Store`,
retaining information about its trampolines, but then instantiation
failed and the module's code was never persisted within the `Store`.
Unlike as documented in #2374 the `Module` inside an `Instance` is not
the primary way to hold on to a module's code, but rather the
`Arc<ModuleCode>` is persisted within the global frame information off
on the side. This persistence only made its way into the store through
the `Box<Any>` field of `InstanceHandle`, but that's never made if
instantiation fails during import matching.
The fix here is to build on the refactoring of #2407 to not store module
code in frame information but rather explicitly in the `Store`.
Registration is now deferred until just-before an instance handle is
created, and during module registration we insert the `Arc<ModuleCode>`
into a set stored within the `Store`.
This commit removes the global variable associated with wasm traps which
stores frame information. The only purpose of this global is to help
symbolicate `Trap`s created since we support creating a `Trap` without a
`Store`. The global, however, is only used for wasm frames on the stack,
and when wasm frames are on the stack we know that our thread local for
"what was the last context" is set and configured.
The change here is to hijack this thread-local some more to effectively
store the `Store` inside of it. All frame information is then moved
directly into `Store` and no longer lives off on the side in a global.
Additionally support for registering/unregistering modules is now
simplified because once a module is registered with a store it can never
be unregistered.
This has one slight functional change where if there are two instances
of `Store` interleaving calls to wasm code on the stack we'll only be
able to symbolicate one of them instead of both. That's arguably also a
feature however because this is sort of a way to leak information across
stores right now.
Otherwise, though, this isn't intended to change any existing logic, but
instead keep everything working as-is.
This file has grown quite a lot with `Store` over time so this splits it
up into three separate files, one for each of the main types defined in
it: `Config`, `Engine`, and `Store`.
This commit fixes an issue where when looking up the stack map for a pc
within a function we might end up reading the *previous* function's
stack maps. This then later caused asserts to trip because we started
interpreting random data as a `VMExternRef` when it wasn't. The fix was
to add `None` markers for "this range has no stack map" in the function
ranges map.
Closes#2386
This commit fixes an issue with reference-types-using-modules where they
panicked on instantiation if any element segments had an externref null
specified.
* this requires upgrading to wasmparser 0.67.0.
* There are no CLIF side changes because the CLIF `select` instruction is
polymorphic enough.
* on aarch64, there is unfortunately no conditional-move (csel) instruction on
vectors. This patch adds a synthetic instruction `VecCSel` which *does*
behave like that. At emit time, this is emitted as an if-then-else diamond
(4 insns).
* aarch64 implementation is otherwise straightforwards.
The JIT build_object routine currently rejects building object files
for any big-endian platform. However, most of the object builder
code works fine for either byte order, with the exception of a small
change in the ObjectBuilderTarget::new routine.
This patch adds that change and removes the assert in build_object.
When invoking a WebAssembly routine from Rust code, arguments
are stored into an array of u128, and read from a piece of
generated trampoline code before calling the compiled target
function using the platform ABI calling convention.
The WasmTy/WasmRet routines handle the conversion between Rust
data types and those u128 buffers. This currently works by
in effect converting the Rust object to a u128 and then storing
this u128 into the buffer. The generated trampoline code will
then read an object of appropriate type from the beginning of
that buffer.
This does not work on big-endian platforms, since the above
approach causes the value to be stored into the rightmost
bytes of the u128 buffer, while the trampoline code reads
the leftmost bytes.
This patch fixes the problem by changing WasmTy/WasmRet to
use the leftmost bytes as well, by casting the u128 pointer
to a pointer of the correct type before storing to it (or
reading from it).
(Note that it is not necessary to actually byte-swap the
values since the trampoline code will not treat them like
WebAssembly little-endian memory, but simply access them
in native byte order.)
The GuestType trait is used to access data elements in guest memory.
According to the WebAssembly spec, those are always stored in
little-endian byte order, even on big-endian hosts. Accessing such
elements on big-endian hosts therefore requires byte swapping.
Fixed by adding from_le_bytes / to_le_bytes.
