|
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 |
|
| #
94740588 |
| 09-Jan-2026 |
Nick Fitzgerald <[email protected]> |
Migrate the Wasmtime CLI to `wasmtime::error` (#12295)
* Migrate wasmtime-cli to `wasmtime::error`
* migrate benches to `wasmtime::error` as well
* Remove new usage of anyhow that snuck in
|
|
Revision tags: v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0, v36.0.2, 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 |
|
| #
90ac295e |
| 19-May-2025 |
Alex Crichton <[email protected]> |
Update Wasmtime to the 2024 Rust Edition (#10806)
* Update Wasmtime to the 2024 Rust Edition
Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim
Update Wasmtime to the 2024 Rust Edition (#10806)
* Update Wasmtime to the 2024 Rust Edition
Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.
prtest:full
* Reformat with the 2024 edition
show more ...
|
|
Revision tags: v32.0.0, v31.0.0, v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0, v28.0.1, v28.0.0 |
|
| #
5eee6313 |
| 10-Dec-2024 |
Chris Fallin <[email protected]> |
Wasmtime: support a notion of "custom code publisher". (#9778)
* Wasmtime: support a notion of "custom code publisher".
In some `no_std` environments, virtual memory usage is *generally*
prohibited
Wasmtime: support a notion of "custom code publisher". (#9778)
* Wasmtime: support a notion of "custom code publisher".
In some `no_std` environments, virtual memory usage is *generally*
prohibited for performance-predictability reasons, but the MMU
hardware is still in use for permissions (e.g., `W^X`
write-xor-execute). Occasional changes to page mapping permissions are
thus necessary when new modules are loaded dynamically, and are
acceptable in that context. Wasmtime needs a way to support
"publishing" code (making it executable) in such environments.
Rather than try to segment the `signals-based-traps` divide further,
and piece out the code-publishing parts from the heap parts, and
backdoor a path to `mprotect` in an otherwise `no_std` build, in this
PR I have opted to add a trait an impl of which the embedder can
provide to the `Config` to implement custom actions for "code
publish". This otherwise operates properly in a
no-`signals-based-traps` environment, e.g., the module backing memory
itself is regularly allocated rather than mmap'd (but is now aligned
to the degree requested by the trait impl).
* Review feedback.
* Plumb through custom alignment for runtime code generation
* Add a test for custom code memory.
show more ...
|