|
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1 |
|
| #
41b081c1 |
| 07-Jan-2026 |
Nick Fitzgerald <[email protected]> |
Migrate the min-platform example to `wasmtime::error` (#12267)
|
|
Revision tags: v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5 |
|
| #
d55a5c8b |
| 29-Oct-2025 |
geogrego <[email protected]> |
docs: minor improvement for docs (#11952)
Signed-off-by: geogrego <[email protected]>
|
|
Revision tags: v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0 |
|
| #
c7dc2d52 |
| 28-Aug-2025 |
Alex Crichton <[email protected]> |
Disallow loading code on `x86_64-unknown-none` (#11553)
* Disallow loading code on `x86_64-unknown-none`
... And then also add an escape hatch to allow loading code. This commit is the culmination
Disallow loading code on `x86_64-unknown-none` (#11553)
* Disallow loading code on `x86_64-unknown-none`
... And then also add an escape hatch to allow loading code. This commit is the culmination of discussion on #11506 with a proposed resolution for Wasmtime. The resolution being:
* Wasmtime will reject loading code on `x86_64-unknown-none` platforms by default. * A new `Config::x86_float_abi_ok` escape hatch is added to bypass this check. * Documentation/errors are updated around `x86_float_abi_ok` to document the situation. * The `min-platform` example is updated to showcase how this is valid to run in that particular embedding (aka enable more features and sufficiently detect said features).
The basic tl;dr; is that we can't detect in stable Rust what float ABI is being used so therefore we pessimistically assume that `x86_64-unknown-none` is using a soft-float ABI. This is incompatible with libcalls unless they aren't actually called which is only possible when sufficiently many target features are enabled.
The goal of this commit is to be a relatively low-effort way to place a roadblock in the way of "ok ABIs are weird" but at the same time enable getting around the roadblock easily. Additionally the roadblock points to documentation about itself to learn more about what's going on here.
Closes #11506
* Add audit of raw-cpuid
* Add back in check
Turns out it doesn't go through the same path as other bits
* Review comments
* Fix running floats without without custom support
show more ...
|
|
Revision tags: v36.0.2 |
|
| #
dcfb6761 |
| 25-Aug-2025 |
Alex Crichton <[email protected]> |
Get the min-platform example working again (#11516)
A few various changes have happened in the meantime which means that this wasn't actually testing anything on CI. Notably these changes were made:
Get the min-platform example working again (#11516)
A few various changes have happened in the meantime which means that this wasn't actually testing anything on CI. Notably these changes were made:
* Sink icache maintenance into `vm::sys` modules. This is fallout of #11152 where no_std support was added for unix/windows targets. This commit moves the error-on-lack-of-std to the `unix` and `windows` modules, relegating the custom module to figure its own pieces out as necessary. This also feels like a more accurate reflection of how responsibilities should be sliced up.
* The example runner now uses `bail!` to return an error in case something bad happens instead of continuing as usual and pretending nothing bad happened.
show more ...
|
|
Revision tags: v36.0.1, v36.0.0, v35.0.0, v24.0.4, v33.0.2, v34.0.2, v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0, v32.0.0 |
|
| #
073aedab |
| 09-Apr-2025 |
Alex Crichton <[email protected]> |
Enable the `unsafe-op-in-unsafe-fn` lint (#10559)
* Enable the `unsafe-op-in-unsafe-fn` lint
This commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for the entire workspace. This lint will
Enable the `unsafe-op-in-unsafe-fn` lint (#10559)
* Enable the `unsafe-op-in-unsafe-fn` lint
This commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for the entire workspace. This lint will be warn-by-default in the 2024 edition so this is intended to smooth the future migration to the new edition.
Many `unsafe` blocks were added in places the lint warned about, with two major exceptions. The `wasmtime` and `wasmtime-c-api` crates simply expect this lint to fire and effectively disable the lint. They're too big at this time to do through this PR. My hope is that one day in the future they'll be migrated, but more realistically that probably won't happen so these crates just won't benefit from this lint.
* Fix nostd fiber build
prtest:full
* Fix build on Windows
* Fix asan build
show more ...
|
|
Revision tags: v31.0.0 |
|
| #
99efc20b |
| 06-Mar-2025 |
Paul Osborne <[email protected]> |
Add Engine/Component::deserialize_raw (#10321)
* Add Engine/Component::deserialize_raw
For targets without virtual memory support, the only mechanism for load code previously was to copy bytes from
Add Engine/Component::deserialize_raw (#10321)
* Add Engine/Component::deserialize_raw
For targets without virtual memory support, the only mechanism for load code previously was to copy bytes from a provided slice into a separate, owned, allocated buffer containing a copy of the serialized module contents. This is expensive for constrained targets and prohibits embedded runtimes like doing things like running code directly out of memory-mapped devices such as NOR flash.
The tradeoff for directly using the externally owned memory is that the caller must ensure that the code memory will not be written to for the lifetime of the CodeMemory.
Loading code from externally owned memory is supported for all configurations but is expected to fail to deserialize on platforms that suport virtual memory and are attempting to load modules or components that require that the memory be made executable (native code rather than pulley).
https://github.com/bytecodealliance/wasmtime/issues/10245
* Fix tests for s390x
Previously, there was a bad assumption that pulley32/64 were the only targets but there's also the "be" variants. Use the `pulley_host` helper to better get the right pulley target for the host.
show more ...
|
|
Revision tags: v30.0.2, v30.0.1, v30.0.0 |
|
| #
b9b0ba49 |
| 28-Jan-2025 |
Pat Hickey <[email protected]> |
add wasmtime-wasi-io and custom async executor to min-platform example (#10128)
* add wasmtime-wasi-io and custom async executor to min-platform example
* make it possible to find example from wasm
add wasmtime-wasi-io and custom async executor to min-platform example (#10128)
* add wasmtime-wasi-io and custom async executor to min-platform example
* make it possible to find example from wasmtime-wasi-io docs
prtest:full
* fix comment
* add wasm32-wasip2 target for min-platform ci
and enable signals based traps when running with wasi disabled, because at the moment without signals based traps no native code can be loaded so the embedding never actually executes wasm. this ensures the heap size setting when not(feature = "wasi") is checked by execution
* fix cbindgen version in ci
show more ...
|
|
Revision tags: v29.0.1, v29.0.0 |
|
| #
7f9049b9 |
| 15-Jan-2025 |
Alex Crichton <[email protected]> |
Replace `signals-based-traps` with auto-detection (#9941)
* Replace `signals-based-traps` with auto-detection
This commit refactors the platform support of the `wasmtime` crate itself to remove the
Replace `signals-based-traps` with auto-detection (#9941)
* Replace `signals-based-traps` with auto-detection
This commit refactors the platform support of the `wasmtime` crate itself to remove the previously added `signals-based-traps` feature in favor of auto-detecting whether it's there or not. The `build.rs` script for the `wasmtime` crate will now detect the target platform and auto-enable this feature as necessary.
The `signals-based-traps` cargo feature is removed and split into two custom `#[cfg]` directives that the build script sets:
* `has_virtual_memory` - this is used to gate mmap implementations for example. This is enabled on `unix || windows` and will be off for `no_std` targets for example. This is split out of "signals-based-traps" to better handle platforms like iOS which have virtual memory but don't execute native code (removing the need for native signals).
* `has_native_signals` - gates signal handlers on Unix for example. This is disabled on MIRI but otherwise enabled for `unix || windows`. This is intended to in the future get disabled for iOS by default for example since it's not necessary when using Pulley. This is additionally off-by-default for `no_std` platforms.
Two new crate features were added for `no_std` or "custom" platforms to opt-in to the `wasmtime-platform.h` C APIs for implementing virtual memory and signals. These are used in the `min-platform` embedding example.
This commit additionally updates some various documentation here and there to be more up-to-date.
* Update CI configuration
* Fix compile warnings
* Fix test on miri
* Fix more tests on miri
* Fix some warnings
* Another round of miri/CI attempts/fixes
prtest:full
show more ...
|
|
Revision tags: v28.0.1 |
|
| #
ae84e6ed |
| 09-Jan-2025 |
Alex Crichton <[email protected]> |
Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)
* Enable `unsafe-attr-outside-unsafe` 2024 edition lint
This commit enables the `unsafe-attr-outside-unsafe` lint in rustc used in tran
Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)
* Enable `unsafe-attr-outside-unsafe` 2024 edition lint
This commit enables the `unsafe-attr-outside-unsafe` lint in rustc used in transitioning to the 2024 edition. This requires that the `#[no_mangle]` attribute is replaced in favor of `#[unsafe(no_mangle)]`. This mostly affects the C API of wasmtime and most of the changes here are a simple search/replace.
* Another attribute update
* Fix command adapter build
show more ...
|
|
Revision tags: v28.0.0, v27.0.0 |
|
| #
d3132c9d |
| 19-Nov-2024 |
Alex Crichton <[email protected]> |
Add a `signals-based-traps` Cargo compile-time feature (#9614)
* Gate signal handlers behind a new Cargo feature
This commit adds a new on-by-default Cargo feature to the `wasmtime` crate named `si
Add a `signals-based-traps` Cargo compile-time feature (#9614)
* Gate signal handlers behind a new Cargo feature
This commit adds a new on-by-default Cargo feature to the `wasmtime` crate named `signals-based-traps`. This is modeled after the `Config::signals_based_traps` configuration at runtime and can be used to statically disable the use of signal handlers in Wasmtime. This notably reduces the number of platform dependencies that Wasmtime has and provides a mode of avoiding relying on signals altogether.
This introduces a new `MallocMemory` which is a linear memory backed by the system allocator. This new type of memory is enabled when virtual memory guards are disabled and signals-based-traps are disabled. This means that this new type of memory will be candidate for fuzzing for example.
prtest:full
* Fix rebase conflict
* Refactor `MmapVec` documentation and representation
* Remove no-longer-needed `Arc` * Document it may be backed by `Vec<u8>`
show more ...
|
|
Revision tags: v26.0.1, v25.0.3, v24.0.2, v26.0.0, v21.0.2, v22.0.1, v23.0.3, v25.0.2, v24.0.1, v25.0.1, v25.0.0, v24.0.0, v23.0.2, v23.0.1, v23.0.0, v22.0.0, v21.0.1, v21.0.0, v20.0.2 |
|
| #
5054d400 |
| 06-May-2024 |
Alex Crichton <[email protected]> |
Update documentation and example for no_std (#8555)
* Update Wasmtime's tier stability documentation
Move some items between tiers and add a few misc items here and there.
* Update platform suppor
Update documentation and example for no_std (#8555)
* Update Wasmtime's tier stability documentation
Move some items between tiers and add a few misc items here and there.
* Update platform support documentation
Re-word lots of this since it was originally written, link to the tiers of support page, and rewrite the section on `no_std`.
* Update the `min-platform` example with no_std
This commit updates the preexisting `min-platform` example to no longer require Nightly Rust and instead use the `no_std` support now added to Wasmtime. This involved:
* Change the build process to produce a staticlib which is then manually converted via `cc` into a shared library for the native Linux platform. * Compile the modules outside of the embedding and only `deserialize` within the embedding. * Update the `indexmap` dependency to pick up a bug fix required in `no_std` mode (apparently, it fails on [email protected] and passes at 2.2.6, I didn't dig much further).
This commit additionally makes the `wasmtime-platform.h` header file generated by the example a release artifact for Wasmtime itself. The header itself is touched up a bit by configuring some more `cbindgen` options as well.
* Fix clippy build
prtest:full
* Review comments
* Pass gc-sections to linking the library
show more ...
|
|
Revision tags: v20.0.1, v20.0.0, v17.0.3, v19.0.2, v18.0.4, v19.0.1, v19.0.0, v18.0.3, v18.0.2, v17.0.2 |
|
| #
b81bb7a3 |
| 28-Feb-2024 |
Alex Crichton <[email protected]> |
Add a "custom" platform configuration for Wasmtime (#7995)
* Add a "custom" platform configuration for Wasmtime
This commit leverages adds a new "platform" to Wasmtime to be supported in the `crate
Add a "custom" platform configuration for Wasmtime (#7995)
* Add a "custom" platform configuration for Wasmtime
This commit leverages adds a new "platform" to Wasmtime to be supported in the `crates/runtime/src/sys` folder. This joins preexisting platforms such as Unix and Windows. The goal of this platform is to be an opt-in way to build Wasmtime for targets that don't have a predefined way to run.
The new "custom" platform requires `--cfg wasmtime_custom_platform` to be passed to the Rust compiler, for example by using `RUSTFLAGS`. This new platform bottoms out in a C API that is intended to be small and Linux-like. The C API is effectively the interface to virtual memory that Wasmtime requires. This C API is also available as a header file at `examples/min-platform/embedding/wasmtime-platform.h` (generated by `cbindgen`).
The main purpose of this is to make it easier to experiment with porting Wasmtime to new platforms. By decoupling a platform implementation from Wasmtime itself it should be possible to run these experiments out-of-tree. An example of this I've been working on is getting Wasmtime running on bare-metal with a custom kernel. This support enables defining the platform interface of the custom kernel's syscalls outside of Wasmtime.
* Exclude wasmtime-platform.h from formatting
* Include build-wasmtime-target-wasm32 in final job
* Don't force any single toolchain
* Add notes to no_std docs
* Add rust-src to CI
* Review comments
* Change APIs to be fallible
* Only compile the min-platform example on Linux
* Fix compile of min-platform example
* Fix another compile error in the example
show more ...
|