Handle OOM in `Linker::func_wrap` (#12537)* Handle OOM in `Linker::func_wrap`* review feedback* fix clippy and certain cfg builds
Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm` (#11312)* Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm`Slowly expanding this lint to more of the crate.prtest:full* Fix lin
Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm` (#11312)* Deny `unsafe_op_in_unsafe_fn` in `wasmtime::runtime::vm`Slowly expanding this lint to more of the crate.prtest:full* Fix lints in custom module* Fix some lints with miri* Fix non-VM build* Fix arm windows
show more ...
Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtim
Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition
Provenance preparation for Pulley (#10043)* Provenance preparation for PulleyThis commit is an internal refactoring of Wasmtime's runtime to prepareto execute Pulley in MIRI. Currently today th
Provenance preparation for Pulley (#10043)* Provenance preparation for PulleyThis commit is an internal refactoring of Wasmtime's runtime to prepareto execute Pulley in MIRI. Currently today this is not possible becausePulley does not properly respect either strict or permissive provenancemodels. The goal of this refactoring is to enable fixing this in afuture commit that doesn't touch everything in the codebase. Insteadeverything is touched here in this commit.The basic problem with Pulley is that it is incompatible with the strictprovenance model of Rust which means that we'll be using "exposedprovenance" APIs to satisfy Rust's soundness requirements. In this modelwe must explicitly call `ptr.expose_provenance()` on any pointerswhich are exposed to compiled code. Arguably we should also be alreadydoing this for natively-compiled code but I am not certain about howstrictly this is required.Currently in Wasmtime today we call `ptr.expose_provenance()` nowhere.It also turns out, though, that we share quite a few pointers in quite afew places with compiled code. This creates a bit of a problem! Thesolution settled on in this commit looks like:* A new marker trait, `VmSafe`, is introduced. This trait is used to represent "safe to share with compiled code" types and enumerates some properties such as defined ABIs, primitives wrappers match primitive ABIs, and notably "does not contain a pointer".* A new type, `VmPtr<T>`, is added to represent pointers shared with compiled code. Internally for now this is just `SendSyncPtr<T>` but in the future it will be `usize`. By using `SendSyncPtr<T>` it shouldn't actually really change anything today other than requiring a lot of refactoring to get the types to line up.* The core `vmctx_plus_offset*` methods are updated to require `T: VmSafe`. Previously they allowed any `T` which is relatively dangerous to store any possible Rust type in Cranelift-accessible areas.These three fundamental changes were introduced in this commit. Allfurther changes were refactoring necessary to get everything workingafter these changes. For example many types in `vmcontext.rs`, such as`VMFuncRef`, have changed to using `VmPtr<T>` instead of `NonNull<T>` or`*mut T`. This is a pretty expansive change which resulted in touching alot of places.One premise of `VmPtr<T>` is that it's non-null. This was anadditional refactoring that updated a lot of places where previously`*mut T` was used and now either `VmPtr<T>` or `NonNull<T>` is used.In the end the intention is that `VmPtr<T>` is used whenever pointersare store in memory that can be accessed from Cranelift. When operatinginside of the runtime `NonNull<T>` or `SendSyncPtr<T>` is preferredinstead.As a final note, no provenance changes have actually happened yet. Forexample this doesn't fix Pulley in MIRI. What it does enable, though, isthat the future commit to fix Pulley in MIRI will be much smaller withthis having already landed.* Run the full test suite in PR CIprtest:full* Minor CI issues* Fix no_std build* Fix miri build* Don't use `VmPtr` in FFI function signaturesUse `NonNull` or `*mut u8` as appropriate for function signaturesinstead. It shouldn't be required to use `VmPtr` during the handoff tocompiled code as we've already annotated the pointer going out.* Fix rebase conflict* Review comments
Change `VMArrayCallFunction` to be an opaque pointer (#9638)This pointer is technically not safe to be a function pointer because itwill get unloaded when the module is dropped. Additionally with
Change `VMArrayCallFunction` to be an opaque pointer (#9638)This pointer is technically not safe to be a function pointer because itwill get unloaded when the module is dropped. Additionally with Pulleythis isn't actually a native function pointer. This builds on #9630 toprepare for future integration with Pulley to ensure that the number oflocations that have to deal with bytecode-vs-native-code are minimized.
Use some new features of Rust 1.77 (#8797)* Migrate usage of the `memoffset` crate to `core::mem::offset_of!`* C-string literals such as `c"foo"` are now possible* Some helpers for fixed-length s
Use some new features of Rust 1.77 (#8797)* Migrate usage of the `memoffset` crate to `core::mem::offset_of!`* C-string literals such as `c"foo"` are now possible* Some helpers for fixed-length slices such as `slice::first_chunk_mut` are starting to stabilize.
Remove the native ABI calling convention from Wasmtime (#8629)* Remove the native ABI calling convention from WasmtimeThis commit proposes removing the "native abi" calling convention usedin Was
Remove the native ABI calling convention from Wasmtime (#8629)* Remove the native ABI calling convention from WasmtimeThis commit proposes removing the "native abi" calling convention usedin Wasmtime. For background this ABI dates back to the origins ofWasmtime. Originally Wasmtime only had `Func::call` and eventually Iadded `TypedFunc` with `TypedFunc::call` and `Func::wrap` for a fasterpath. At the time given the state of trampolines it was easiest to callWebAssembly code directly without any trampolines using the native ABIthat wasm used at the time. This is the original source of the nativeABI and it's persisted over time under the assumption that it's fasterthan the array ABI due to keeping arguments in registers rather thanspilling them to the stack.Over time, however, this design decision of using the native ABI has notaged well. Trampolines have changed quite a lot in the meantime and it'sno longer possible for the host to call wasm without a trampoline, forexample. Compilations nowadays maintain both native and arraytrampolines for wasm functions in addition to host functions. There's alarge split between `Func::new` and `Func::wrap`. Overall, there's quitea lot of weight that we're pulling for the design decision of using thenative ABI.Functionally this hasn't ever really been the end of the world.Trampolines aren't a known issue in terms of performance or code size.There's no known faster way to invoke WebAssembly from the host (orvice-versa). One major downside of this design, however, is that`Func::new` requires Cranelift as a backend to exist. This is due to thefact that it needs to synthesize various entries in the matrix of ABIswe have that aren't available at any other time. While this is itselfnot the worst of issues it means that the C API cannot be built withouta compiler because the C API does not have access to `Func::wrap`.Overall I'd like to reevaluate given where Wasmtime is today whether itmakes sense to keep the native ABI trampolines. Sure they're supposed tobe fast, but are they really that much faster than the array-call ABI asan alternative? This commit is intended to measure this.This commit removes the native ABI calling convention entirely. Forexample `VMFuncRef` is now one pointer smaller. All of `TypedFunc` nowuses `*mut ValRaw` for loads/stores rather than dealing with ABIbusiness. The benchmarks with this PR are:* `sync/no-hook/core - host-to-wasm - typed - nop` - 5% faster* `sync/no-hook/core - host-to-wasm - typed - nop-params-and-results` - 10% slower* `sync/no-hook/core - wasm-to-host - typed - nop` - no change* `sync/no-hook/core - wasm-to-host - typed - nop-params-and-results` - 7% fasterThese numbers are a bit surprising as I would have suspected no changein both "nop" benchmarks as well as both being slower in theparams-and-results benchmarks. Regardless it is apparent that this isnot a major change in terms of performance given Wasmtime's currentstate. In general my hunch is that there are more expensive sources ofoverhead than reads/writes from the stack when dealing with wasm values(e.g. trap handling, store management, etc).Overall this commit feels like a large simplification of what wecurrently do in `TypedFunc`:* The number of ABIs that Wasmtime deals with is reduced by one. ABIs are pretty much always tricky and having fewer moving parts should help improve the understandability of the system.* All of the `WasmTy` trait methods and `TypedFunc` infrastructure is simplified. Traits now work with simple `load`/`store` methods rather than various other flavors of conversion.* The multi-return-value handling of the native ABI is all gone now which gave rise to significant complexity within Wasmtime's Cranelift translation layer in addition to the `TypedFunc` backing traits.* This aligns components and core wasm where components always use the array ABI and now core wasm additionally will always use the array ABI when communicating with the host.I'll note that this still leaves a major ABI "complexity" with respectto native functions do not have a wasm ABI function pointer untilthey're "attached" to a `Store` with a `Module`. That's required toavoid needing Cranelift for creating host functions and that property isstill true today. This is a bit simpler to understand though now that`Func::new` and `Func::wrap` are treated uniformly rather than one beingspecial-cased.* Fix miri unsafetyprtest:full
Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime's platform support to no longer require anopt-in `RUSTF
Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime's platform support to no longer require anopt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becomingofficially supported this should provide a better onboarding experiencewhere the fallback custom platform is used. This will cause linkererrors if the symbols aren't implemented and searching/googling shouldlead back to our docs/repo (eventually, hopefully).* Change Wasmtime's TLS state to a single pointerThis commit updates the management of TLS to rely on just a singlepointer rather than a pair of a pointer and a `bool`. Additionallymanagement of the TLS state is pushed into platform-specific modules toenable different means of managing it, namely the "custom" platform nowhas a C function required to implement TLS state for Wasmtime.* Delay conversion to `Instant` in atomic intrinsicsThe `Duration` type is available in `no_std` but the `Instant` type isnot. The intention is to only support the `threads` proposal if `std` isactive but to assist with this split push the `Duration` further intoWasmtime to avoid using a type that can't be mentioned in `no_std`.* Gate more parts of Wasmtime on the `profiling` featureMove `serde_json` to an optional dependency and gate the guest profilerentirely on the `profiling` feature.* Refactor conversion to `anyhow::Error` in `wasmtime-environ`Have a dedicated trait for consuming `self` in addition to a`Result`-friendly trait.* Gate `gimli` in Wasmtime on `addr2line`Cut down the dependency list if `addr2line` isn't enabled since thenthe dependency is not used. While here additionally lift the versionrequirement for `addr2line` up to the workspace level.* Update `bindgen!` to have `no_std`-compatible outputPull most types from Wasmtime's `__internal` module as the source oftruth.* Use an `Option` for `gc_store` instead of `OnceCell`No need for synchronization here when mutability is already available inthe necessary contexts.* Enable embedder-defined host feature detection* Add `#![no_std]` support to the `wasmtime` crateThis commit enables compiling the `runtime`, `gc`, and `component-model`features of the `wasmtime` crate on targets that do not have `std`. Thistags the crate as `#![no_std]` and then updates everything internally toimport from `core` or `alloc` and adapt for the various idioms. Thisended up requiring some relatively extensive changes, but nothing tootoo bad in the grand scheme of things.* Require `std` for the perfmap profiling agentprtest:full* Fix build on wasm* Fix windows build* Remove unused import* Fix Windows/Unix build without `std` feature* Fix some doc links* Remove unused import* Fix build of wasi-common in isolation* Fix no_std build on macos* Re-fix build* Fix standalone build of wasmtime-cli-flags* Resolve a merge conflict* Review comments* Remove unused import
Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate* Rewrite uses of `wasmtime
Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate* Rewrite uses of `wasmtime_runtime` to `crate::runtime::vm`* Remove dep on `wasmtime-runtime` from `wasmtime-cli`* Move the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module* Update labeler for merged crates* Fix `publish verify`prtest:full