Changes in diff_wasmtime.rs

332b4ce6 - fuzz: Enable winch-aarch64 (#12646)

Tue, 24 Feb 2026 16:55:02 +0000

fuzz: Enable winch-aarch64 (#12646)As of https://github.com/bytecodealliance/wasmtime/pull/11051, Winchsupports all of Core Wasm on aarch64. This commit enables fuzzingrespectively. List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

93d22fcd - Migrate fuzzing to `wasmtime::error` (#12263)

Wed, 07 Jan 2026 21:51:23 +0000

Migrate fuzzing to `wasmtime::error` (#12263)* Migrate fuzzing to `wasmtime::error`* fix List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

a631d20a - cranelift: stack-switching support (#11003)

Thu, 04 Sep 2025 21:58:01 +0000

cranelift: stack-switching support (#11003)* cranelift: stack-switching supportThis initial commit represents the "pr2" base commit withminimal merge conflicts resolved. Due to OOB conflicts, thiscommit is not functional as-is, but using it as a base inorder to allow for easier reviewing of the delta fromthis commit to what will be used for the PR against upstream.Co-authored-by: Daniel Hillerström Co-authored-by: Paul Osborne * cranelift: stack-switching updates pass 1This first set of changes updates the base pr in order tocompiled and pass basic checks (compile, clippy, fmt) withthe biggest part of the change being to eliminate injectionof tracing/assertions in JIT'ed code.* cranelift: stack-switching: restore original visibility for a few func_environ members* cranelift: stack-switching conditional compilationAt this point, the only bit we really branch on is what wedo in order to avoid problems tying into wasmtime_environ.This is basd on the approach and macro used by the gc code forconverting presence/absence of the cranelift feature flag tocranelift compile time. This is a bit of a half-measure for nowas we still compile most stack-switching code in cranelift, butthis does enough to avoid causing problems with missing definitionsin wasmtime_environ.* cranelift: avoid "as" casts in stack-switchingReplace either with infallible From or fallible, panicingTryFrom alternatives where required.* cranelift: cleanup stack-switching control_effect signaturesAfter removing emission of runtime trace logging and assertions,there were several unused parameters. Remove those from theControlEffect signatures completely.* cranelift: rename stack-switching VMArray to VMHostArrayThis matches a change to the mirrored runtime type inthe upstream changes.* stack-switching: fix typoCo-authored-by: Daniel Hillerström * stack-switching: used Index impl for get_stack_slot_data* stack-switching: use smallvec over vec in several cases* stack-switching: avoid resumetable naming confusion* stack-switching: cleanup unused params from unchecked_get_continuationThe extra parameters here used to be used for emitting runtimeassertions, but with those gone we just had unused paramsand lifetimes, clean those out.* stack_switching: simplify store_data_entries assertion* stack-switching: simplify translate_table_{grow,fill} control flow* stack-switching: remove translate_resume_throw stubThere's already a stub elsewhere and this is not called, whenexceptions are added and it is time to revisit, this methodcan be restored.* stack-switching: compute control_context_size based on target triple* stack-switching: VMHostArrayRef updatesRename VMHostArray -> VMHostArrayRefChange impl to compute address with offset upfront rather thanon each load.* stack-switching: move cranelift code to live under func_environThis matches the directory structure for gc and aids in visibilityfor a few members required by stack-switching code in cranelift.* stack-switching: formatting fix* stack-switching: reduce visibility on a few additional items* stack-switching: simplify contobj fatptr con/de-struction* stack-switching: add disas tests to cover new instructions* stack-switching: fix layout of VMContObjIn the course of the various runtime updates, the layout of theruntime VMContObj got switched around. This resulted in failureswhen doing certain table operations on continuations.This change fixes that layout problem and adds some tests withoffsets to avoid the problem. Due to the way that we interactwith the VMContObj in cranelift, we don't use these offsets outsideof the tests.* Fix formatting of merge conflict resolution* cranelift: remove ir::function::get_stack_slot_dataThis method isn't required as sized_stack_slots is already pub.* stack-switching: reduce visibility of a couple func_environ methods* stack-switching: define VMContObj as two wordsThis change migrates VMContObj and its usages in cranelift and runtimeto work with the VMContObj fat pointer as two words in order to bettertarget different architectures (still gated to x86_64 for now).To support this, a size type was plumbed into the builtins functionsignature types (as is done for component types) that maps tousize.* fixup! stack-switching: define VMContObj as two words* stack-switching: add stub Val::ContRefThis type is not fully complete until continuation/gc integrationis revisited (#10248) but without these changes, test cases arenow failing on panics as we need some representation ofcontinuation references in the runtime Val enumeration.Runtime errors with TODO notes are added for the stubbedcode paths to revisit later.* fixup! stack-switching: add stub Val::ContRef* fixup! stack-switching: add stub Val::ContRef* fixup! stack-switching: define VMContObj as two wordsprtest:full* stack-switching: don't conflate host and target pointer sizesDisas tests were failing on i686 targeting x86_64 as the size of thehost pointer was leaking into what we were using to do codegenin a few paths. This patch is a bit of a hack as it seems likeusing a generic for T: *mut u8 (as an example) is a bitquestionable. To keep things small, I do a hacky typecheck to mappointers to the target pointer size here.* stack-switching: VMHostArray entry sizes based off env PtrSizeRevisiting the previous commit with an approach that should beless brittle.---------Co-authored-by: Frank Emrich Co-authored-by: Daniel Hillerström List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

eaa4632e - Implement exception objects. (#11230)

Tue, 15 Jul 2025 17:15:35 +0000

Implement exception objects. (#11230)* WIP: Working exception objects* Clean build with gc disabled (`cargo check -p wasmtime --no-default-features --features runtime`).* Review feedback.* Stub out C-API support.* Fix Clippy complaints.* Fix dead-code warning in c-api build.* Actually fix 27->26 reserved bit rename and test.* Fix exnref doc-test.* fix fuzzing build* fix feature-flagging on Instance::id* Bless disas test diff due to reserved-bits change.* Review feedback. List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

d3e7548e - Enable the `from_over_into` Clippy lint (#10837)

Tue, 27 May 2025 15:15:37 +0000

Enable the `from_over_into` Clippy lint (#10837)This requires implementing `From for U` instead of `Into for T`.While both trait impls are valid the `From` one is more useful becauseit implies `Into` and additionally gives you `From`. This additionallythen migrates the existing codebase to using the new style of impls. List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

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 List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

5b9e8765 - Enable the GC proposal during general fuzzing (#10332)

Wed, 12 Mar 2025 18:35:54 +0000

Enable the GC proposal during general fuzzing (#10332)* Enable the GC proposal during general fuzzingThis allows us to fuzz Wasm GC in our fuzz targets that use the commonconfig-generation infrastructure, such as the differential fuzz target.Fixes #10328* Make handling of non-deterministic errors more robust in differential fuzzer* remove logging from functions that can be called from signal handlers List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

c78d44ef - Enable fuzzing for Pulley & Winch (#9966)

Mon, 13 Jan 2025 18:17:02 +0000

Enable fuzzing for Pulley & Winch (#9966)* Enable fuzzing for Pulley & WinchThis commit refactors the `wasmtime-fuzzing` crate to enable fuzzing thePulley interpreter and the Winch compiler more often. Winch has beenfeature-complete for much of wasm for a good amount of time now andPulley now supports many wasm proposals as well. Both strategies havewasm proposals that are still disabled, however.I've run fuzzers for a bit locally and haven't turned up too too much,but I'm sure OSS-Fuzz will chastise me and tell me all the places I'mforgetting to add various configs and tweaks.* Fix test build List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

b3b50943 - Improve some logging in the differential fuzzer (#9982)

Mon, 13 Jan 2025 17:54:31 +0000

Improve some logging in the differential fuzzer (#9982)Clearly show "lhs" and "rhs" more often and then also swap the order ofthe arguments in `assert_error_match` to match the "lhs" and "rhs"terminology of the original execution. List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

ec3b2d22 - Implement most `array.*` instructions for the GC proposal (#9326)

Mon, 30 Sep 2024 19:25:35 +0000

Implement most `array.*` instructions for the GC proposal (#9326)* Implement most `array.*` instructions for the GC proposalThis does not implement `array.copy` and `array.init_elem` yet, but implementsall other `array.*` instructions:* `array.new`* `array.new_fixed`* `array.new_default`* `array.new_data`* `array.new_elem`* `array.fill`* `array.init_data`* `array.len`* `array.get`* `array.get_s`* `array.get_u`* `array.set`Note that the initial plumbing for `array.{copy,init_elem}` is in place, but theinstructions themselves are not implemented yet.* Fix no-gc builds* Fix some clippy warnings* cargo fmt* Fix another clippy error* Fix more clippy errors* Remove debug logging* Add array.fill helper* exit scope even on panic List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

7b744a9d - Make host trap handlers optional (#9230)

Fri, 13 Sep 2024 16:52:28 +0000

Make host trap handlers optional (#9230)* Make host trap handlers optionalThis commit introduces a new configuration option`Config::host_trap_handlers` which enables disabling the reliance onhost trap handlers (e.g. signal handlers on Unix) at runtime. Thisis intended to help increase portability in cases where signal handlersare otherwise difficult. This is achieved by plumbing the translationenvironment to more locations which now conditionally lowers to calls toa function to raise a trap instead of a trap instruction.The caveats of this support are:* This is not yet implemented for Winch* This requires disabling spectre mitigations* This does not yet support shared memories since it forces dynamic memories to be used.These points are all possible to address but it might be best to see howthis feature evolves over time. I'll also note that this is not anoptimized implementation and likely has a fair bit of overhead. Forexample the solution in #6926 of a more optimized stub to jump-and-trapis not implemented yet.Closes #6926* Fix build* Fix clippy warnings* Review comments* Ignore new test on miri List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)

Mon, 05 Aug 2024 09:59:59 +0000

Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

0fa13013 - Add `GcRuntime` and `GcCompiler` traits; `i31ref` support (#8196)

Thu, 04 Apr 2024 00:24:50 +0000

Add `GcRuntime` and `GcCompiler` traits; `i31ref` support (#8196)\### The `GcRuntime` and `GcCompiler` TraitsThis commit factors out the details of the garbage collector away from the restof the runtime and the compiler. It does this by introducing two new traits,very similar to a subset of [those proposed in the Wasm GC RFC], although notall equivalent functionality has been added yet because Wasmtime doesn'tsupport, for example, GC structs yet:[those proposed in the Wasm GC RFC]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasm-gc.md#defining-the-pluggable-gc-interface1. The `GcRuntime` trait: This trait defines how to create new GC heaps, run collections within them, and execute the various GC barriers the collector requires. Rather than monomorphize all of Wasmtime on this trait, we use it as a dynamic trait object. This does imply some virtual call overhead and missing some inlining (and resulting post-inlining) optimization opportunities. However, it is *much* less disruptive to the existing embedder API, results in a cleaner embedder API anyways, and we don't believe that VM runtime/embedder code is on the hot path for working with the GC at this time anyways (that would be the actual Wasm code, which has inlined GC barriers and direct calls and all of that). In the future, once we have optimized enough of the GC that such code is ever hot, we have options we can investigate at that time to avoid these dynamic virtual calls, like only enabling one single collector at build time and then creating a static type alias like `type TheOneGcImpl = ...;` based on the compile time configuration, and using this type alias in the runtime rather than a dynamic trait object. The `GcRuntime` trait additionally defines a method to reset a GC heap, for use by the pooling allocator. This allows reuse of GC heaps across different stores. This integration is very rudimentary at the moment, and is missing all kinds of configuration knobs that we should have before deploying Wasm GC in production. This commit is large enough as it is already! Ideally, in the future, I'd like to make it so that GC heaps receive their memory region, rather than allocate/reserve it themselves, and let each slot in the pooling allocator's memory pool be *either* a linear memory or a GC heap. This would unask various capacity planning questions such as "what percent of memory capacity should we dedicate to linear memories vs GC heaps?". It also seems like basically all the same configuration knobs we have for linear memories apply equally to GC heaps (see also the "Indexed Heaps" section below).2. The `GcCompiler` trait: This trait defines how to emit CLIF that implements GC barriers for various operations on GC-managed references. The Rust code calls into this trait dynamically via a trait object, but since it is customizing the CLIF that is generated for Wasm code, the Wasm code itself is not making dynamic, indirect calls for GC barriers. The `GcCompiler` implementation can inline the parts of GC barrier that it believes should be inline, and leave out-of-line calls to rare slow paths.All that said, there is still only a single implementation of each of thesetraits: the existing deferred reference-counting (DRC) collector. So there is abunch of code motion in this commit as the DRC collector was further isolatedfrom the rest of the runtime and moved to its own submodule. That said, this wasnot *purely* code motion (see "Indexed Heaps" below) so it is worth not simplyskipping over the DRC collector's code in review.\### Indexed HeapsThis commit does bake in a couple assumptions that must be shared across allcollector implementations, such as a shared `VMGcHeader` that all objectsallocated within a GC heap must begin with, but the most notable andfar-reaching of these assumptions is that all collectors will use "indexedheaps".What we are calling indexed heaps are basically the three following invariants:1. All GC heaps will be a single contiguous region of memory, and all GC objects will be allocated within this region of memory. The collector may ask the system allocator for additional memory, e.g. to maintain its free lists, but GC objects themselves will never be allocated via `malloc`.2. A pointer to a GC-managed object (i.e. a `VMGcRef`) is a 32-bit offset into the GC heap's contiguous region of memory. We never hold raw pointers to GC objects (although, of course, we have to compute them and use them temporarily when actually accessing objects). This means that deref'ing GC pointers is equivalent to deref'ing linear memory pointers: we need to add a base and we also check that the GC pointer/index is within the bounds of the GC heap. Furthermore, compressing 64-bit pointers into 32 bits is a fairly common technique among high-performance GC implementations[^compressed-oops][^v8-ptr-compression] so we are in good company.3. Anything stored inside the GC heap is untrusted. Even each GC reference that is an element of an `(array (ref any))` is untrusted, and bounds checked on access. This means that, for example, we do not store the raw pointer to an `externref`'s host object inside the GC heap. Instead an `externref` now stores an ID that can be used to index into a side table in the store that holds the actual `Box` host object, and accessing that side table is always checked.[^compressed-oops]: See ["Compressed OOPs" in OpenJDK.](https://wiki.openjdk.org/display/HotSpot/CompressedOops)[^v8-ptr-compression]: See [V8's pointer compression](https://v8.dev/blog/pointer-compression).The good news with regards to all the bounds checking that this scheme impliesis that we can use all the same virtual memory tricks that linear memories useto omit explicit bounds checks. Additionally, (2) means that the sizes of GCobjects is that much smaller (and therefore that much more cache friendly)because they are only holding onto 32-bit, rather than 64-bit, references toother GC objects. (We can, in the future, support GC heaps up to 16GiB in sizewithout losing 32-bit GC pointers by taking advantage of `VMGcHeader` alignmentand storing aligned indices rather than byte indices, while still leaving thebottom bit available for tagging as an `i31ref` discriminant. Should we everneed to support even larger GC heap capacities, we could go to full 64-bitreferences, but we would need explicit bounds checks.)The biggest benefit of indexed heaps is that, because we are (explicitly orimplicitly) bounds checking GC heap accesses, and because we are not otherwisetrusting any data from inside the GC heap, we greatly reduce how badly thingscan go wrong in the face of collector bugs and GC heap corruption. We areessentially sandboxing the GC heap region, the same way that linear memory is asandbox. GC bugs could lead to the guest program accessing the wrong GC object,or getting garbage data from within the GC heap. But only garbage data fromwithin the GC heap, never outside it. The worse that could happen would be if wedecided not to zero out GC heaps between reuse across stores (which is a validtrade off to make, since zeroing a GC heap is a defense-in-depth techniquesimilar to zeroing a Wasm stack and not semantically visible in the absence ofGC bugs) and then a GC bug would allow the current Wasm guest to read old GCdata from the old Wasm guest that previously used this GC heap. But again, itcould never access host data.Taken altogether, this allows for collector implementations that are nearly freefrom `unsafe` code, and unsafety can otherwise be targeted and limited in scope,such as interactions with JIT code. Most importantly, we do not have to maintaincritical invariants across the whole system -- invariants which can't be nicelyencapsulated or abstracted -- to preserve memory safety. Such holisticinvariants that refuse encapsulation are otherwise generally a huge safetyproblem with GC implementations.\### `VMGcRef` is *NOT* `Clone` or `Copy` Anymore`VMGcRef` used to be `Clone` and `Copy`. It is not anymore. The motivation herewas to be sure that I was actually calling GC barriers at all the correctplaces. I couldn't be sure before. Now, you can still explicitly copy a raw GCreference without running GC barriers if you need to and understand why that'sokay (aka you are implementing the collector), but that is something you have toopt into explicitly by calling `unchecked_copy`. The default now is that youcan't just copy the reference, and instead call an explicit `clone` method (not*the* `Clone` trait, because we need to pass in the GC heap context to run theGC barriers) and it is hard to forget to do that accidentally. This resulted ina pretty big amount of churn, but I am wayyyyyy more confident that the correctGC barriers are called at the correct times now than I was before.\### `i31ref`I started this commit by trying to add `i31ref` support. And it grew into thewhole traits interface because I found that I needed to abstract GC barriersinto helpers anyways to avoid running them for `i31ref`s, so I figured that Imight as well add the whole traits interface. In comparison, `i31ref` support ismuch easier and smaller than that other part! But it was also difficult to pullapart from this commit, sorry about that!---------------------Overall, I know this is a very large commit. I am super happy to have somesynchronous meetings to walk through this all, give an overview of thearchitecture, answer questions directly, etc... to make review easier!prtest:full List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

ff93bce0 - Wasmtime: Finish support for the typed function references proposal (#7943)

Tue, 20 Feb 2024 20:33:28 +0000

Wasmtime: Finish support for the typed function references proposal (#7943)* Wasmtime: Finish support for the typed function references proposalWhile we supported the function references proposal inside Wasm, we didn'tsupport it on the "outside" in the Wasmtime embedder APIs. So much of the workhere is exposing typed function references, and their type system updates, inthe embedder API. These changes include:* `ValType::FuncRef` and `ValType::ExternRef` are gone, replaced with the introduction of the `RefType` and `HeapType` types and a `ValType::Ref(RefType)` variant.* `ValType` and `FuncType` no longer implement `Eq` and `PartialEq`. Instead there are `ValType::matches` and `FuncType::matches` methods which check directional subtyping. I also added `ValType::eq` and `FuncType::eq` static methods for the rare case where someone needs to check precise equality, but that is almost never actually the case, 99.99% of the time you want to check subtyping.* There are also public `Val::matches_ty` predicates for checking if a value is an instance of a type, as well as internal helpers like `Val::ensure_matches_ty` that return a formatted error if the value does not match the given type. These helpers are used throughout Wasmtime internals now.* There is now a dedicated `wasmtime::Ref` type that represents reference values. Table operations have been updated to take and return `Ref`s rather than `Val`s.Furthermore, this commit also includes type registry changes to correctly managelifetimes of types that reference other types. This wasn't previously an issuebecause the only thing that could reference types that reference other types wasa Wasm module that added all the types that could reference each other at thesame time and removed them all at the same time. But now that the previouslydiscussed work to expose these things in the embedder API is done, type lifetimemanagement in the registry becomes a little trickier because the embedder mightgrab a reference to a type that references another type, and then unload theWasm module that originally defined that type, but then the user should still beable use that type and the other types it transtively references. Before, wewere refcounting individual registry entries. Now, we still are refcountingindividual entries, but now we are also accounting for type-to-type referencesand adding a new type to the registry will increment the refcounts of each ofthe types that it references, and removing a type from the registry willdecrement the refcounts of each of the types it references, and then recursively(logically, not literally) remove any types whose refcount has now reached zero.Additionally, this PR adds support for subtyping to `Func::typed`- and`Func::wrap`-style APIs. For result types, you can always use a supertype of theWebAssembly function's actual declared return type in `Func::typed`. And forparam types, you can always use a subtype of the Wasm function's actual declaredparam type. Doing these things essentially erases information but is alwayscorrect. But additionally, for functions which take a reference to a concretetype as a parameter, you can also use the concrete type's supertype. Consider aWebAssembly function that takes a reference to a function with a concrete type:`(ref null )`. In this scenario, there is no static`wasmtime::Foo` Rust type that corresponds to that particular Wasm-definedconcrete reference type because Wasm modules are loaded dynamically atruntime. You *could* do `f.typed::, ()>()`, and while that iscorrectly typed and valid, it is often overly restrictive. The only value youcould call the resulting typed function with is the null function reference, butwe'd like to call it with non-null function references that happen to be of thecorrect type. Therefore, `f.typed, ()>()` is also allowed in thiscase, even though `Option` represents `(ref null func)` which is thesupertype, not subtype, of `(ref null )`. This does imply someminimal dynamic type checks in this case, but it is supported for betterergonomics, to enable passing non-null references into the function.We can investigate whether it is possible to use generic type parameters andcombinators to define Rust types that precisely match concrete reference typesin future, follow-up pull requests. But for now, we've made things usable, atleast.Finally, this also takes the first baby step towards adding support for the WasmGC proposal. Right now the only thing that is supported is `nofunc` references,and this was mainly to make testing function reference subtyping easier. Butthat does mean that supporting `nofunc` references entailed also adding a`wasmtime::NoFunc` type as well as the `Config::wasm_gc(enabled)` knob. So weofficially have an in-progress implementation of Wasm GC in Wasmtime after thisPR lands!Fixes https://github.com/bytecodealliance/wasmtime/issues/6455* Fix WAT in test to be valid* Check that dependent features are enabled for function-references and GC* Remove unnecessary engine parameters from a few methodsEver since `FuncType`'s internal `RegisteredType` holds onto its own `Engine`,we don't need these anymore.Still useful to keep the `Engine` parameter around for the `ensure_matches`methods because that can be used to check correct store/engine usage forembedders.* Add missing dependent feature enabling for some tests* Remove copy-paste bit from test* match self to show it is uninhabited* Add a missing `is_v128` method* Short circuit a few func type comparisons* Turn comment into part of doc comment* Add test for `Global::new` and subtyping* Add tests for embedder API, tables, and subtyping* Add an embedder API test for setting globals and subtyping* Construct realloc's type from its index, rather than from scratch* Help LLVM better optimize our dynamic type checks in `TypedFunc::call_raw`* Fix call benchmark compilation* Change `WasmParams::into_abi` to take the whole func type instead of iter of params* Fix doc linksprtest:full* Fix size assertion on s390x List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

353dc273 - Fully enable Winch in the `differential` fuzzer (#7932)

Wed, 14 Feb 2024 15:10:32 +0000

Fully enable Winch in the `differential` fuzzer (#7932)This commit fully enables usage of Winch in the `differential` fuzzeragainst all other engines with no special cases. I attempted enablingwinch for the other fuzzers as well but Winch doesn't currentlyimplement all methods for generating various trampolines required soit's currently only limited to the `differential` fuzzer.This adds Winch as an "engine" and additionally ensures that whenconfigured various wasm proposals are disabled that Winch doesn'tsupport (similar to how enabling `wasmi` disables proposals that `wasmi`doesn't support).This does reduce fuzzing of Winch slightly in that the reference-typesproposal is completely disabled for Winch rather than half-enabled whereWinch doesn't implement `externref` operations yet but does implement`funcref` operations. This, however, enables integrating it more cleanlyinto the rest of the fuzzing infrastructure with fewer special cases. List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

04c03b31 - Update the wasm-tools family of crates (#7921)

Mon, 12 Feb 2024 23:22:16 +0000

Update the wasm-tools family of crates (#7921)* Update the wasm-tools family of cratesPulling in some updates to improve how WIT is managed in thisrepository. No changes just yet, however, just pulling in the updatesfirst.* Fix tests* Fix fuzzer build List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

8d7a2b89 - Add support for `v128` to the typed function API (#7010)

Thu, 14 Sep 2023 15:57:34 +0000

Add support for `v128` to the typed function API (#7010)* Add support for `v128` to the typed function APIThis commit adds a Rust type `V128` which corresponds to the wasm`v128` type. This is intended to perhaps one day have accessors forlanes of various sizes but in the meantime only supports conversion backand forth between `u128`. The intention of this type is to allowplatforms to perform typed between to functions that take or return`v128` wasm values.Previously this was not implemented because it's a bit tricky ABI-wise.Typed functions work by passing arguments in registers which requiresthe calling convention to match in both Cranelift and in Rust. Thisshould be the case for supported platforms and the default callingconvention, especially now that the wasm calling convention is separatefrom the platform calling convention. This does mean, however, that thisfeature can only be supported on x86_64 and AArch64. Currently neithers390x nor RISC-V have a means of supporting the vector callingconvention since the vector types aren't available on stable in Rustitself. This means that it's now unfortunately possible to write aWasmtime embedding that compiles on x86_64 that doesn't compile on s390xfor example, but given how niche this feature is that seems like an oktradeoff for now and by the time it's a problem Rust might have nativestable support for vector types on these platforms.prtest:full* Fix compile of C API* Conditionally enable typed v128 tests* Review comments* Fix compiler warnings List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

4b703f9d - Fix differential fuzzing when Wasmtime hits an OOM (#6273)

Mon, 24 Apr 2023 16:00:24 +0000

Fix differential fuzzing when Wasmtime hits an OOM (#6273)OSS-Fuzz found a case where the `differential` fuzzer was failing andthe underlying cause was that Wasmtime was hitting an OOM while Wasmiwasn't. This meant that the two modules were producing "differentresults" since memories had differing lengths, but this isn't a failurewe're interested in. This commit updates the differential fuzzer todiscard the test case once the Wasmtime half reaches OOM. List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

2be457c2 - Change the return type of `SharedMemory::data` (#5240)

Thu, 10 Nov 2022 17:51:10 +0000

Change the return type of `SharedMemory::data` (#5240)This commit is an attempt at improving the safety of using the return value of the `SharedMemory::data` method. Previously this returned `*mut [u8]` which, while correct, is unwieldy and unsafe to work with. The new return value of `&[UnsafeCell]` has a few advantages: * The lifetime of the returned data is now connected to the `SharedMemory` itself, removing the possibility for a class of errors of accidentally using the prior `*mut [u8]` beyond its original lifetime. * It's not possibly to safely access `.len()` as opposed to requiring an `unsafe` dereference before. * The data internally within the slice is now what retains the `unsafe` bits, namely indicating that accessing any memory inside of the contents returned is `unsafe` but addressing it is safe. I was inspired by the `wiggle`-based discussion on #5229 and felt it appropriate to apply a similar change here. List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs

2afaac51 - Return `anyhow::Error` from host functions instead of `Trap`, redesign `Trap` (#5149)

Wed, 02 Nov 2022 16:29:31 +0000

Return `anyhow::Error` from host functions instead of `Trap`, redesign `Trap` (#5149)* Return `anyhow::Error` from host functions instead of `Trap` This commit refactors how errors are modeled when returned from host functions and additionally refactors how custom errors work with `Trap`. At a high level functions in Wasmtime that previously worked with `Result` now work with `Result` instead where the error is `anyhow::Error`. This includes functions such as: * Host-defined functions in a `Linker` * `TypedFunc::call` * Host-related callbacks like call hooks Errors are now modeled primarily as `anyhow::Error` throughout Wasmtime. This subsequently removes the need for `Trap` to have the ability to represent all host-defined errors as it previously did. Consequently the `From` implementations for any error into a `Trap` have been removed here and the only embedder-defined way to create a `Trap` is to use `Trap::new` with a custom string. After this commit the distinction between a `Trap` and a host error is the wasm backtrace that it contains. Previously all errors in host functions would flow through a `Trap` and get a wasm backtrace attached to them, but now this only happens if a `Trap` itself is created meaning that arbitrary host-defined errors flowing from a host import to the other side won't get backtraces attached. Some internals of Wasmtime itself were updated or preserved to use `Trap::new` to capture a backtrace where it seemed useful, such as when fuel runs out. The main motivation for this commit is that it now enables hosts to thread a concrete error type from a host function all the way through to where a wasm function was invoked. Previously this could not be done since the host error was wrapped in a `Trap` that didn't provide the ability to get at the internals. A consequence of this commit is that when a host error is returned that isn't a `Trap` we'll capture a backtrace and then won't have a `Trap` to attach it to. To avoid losing the contextual information this commit uses the `Error::context` method to attach the backtrace as contextual information to ensure that the backtrace is itself not lost. This is a breaking change for likely all users of Wasmtime, but it's hoped to be a relatively minor change to workaround. Most use cases can likely change `-> Result` to `-> Result` and otherwise explicit creation of a `Trap` is largely no longer necessary. * Fix some doc links * add some tests and make a backtrace type public (#55) * Trap: avoid a trailing newline in the Display impl which in turn ends up with three newlines between the end of the backtrace and the `Caused by` in the anyhow Debug impl * make BacktraceContext pub, and add tests showing downcasting behavior of anyhow::Error to traps or backtraces * Remove now-unnecesary `Trap` downcasts in `Linker::module` * Fix test output expectations * Remove `Trap::i32_exit` This commit removes special-handling in the `wasmtime::Trap` type for the i32 exit code required by WASI. This is now instead modeled as a specific `I32Exit` error type in the `wasmtime-wasi` crate which is returned by the `proc_exit` hostcall. Embedders which previously tested for i32 exits now downcast to the `I32Exit` value. * Remove the `Trap::new` constructor This commit removes the ability to create a trap with an arbitrary error message. The purpose of this commit is to continue the prior trend of leaning into the `anyhow::Error` type instead of trying to recreate it with `Trap`. A subsequent simplification to `Trap` after this commit is that `Trap` will simply be an `enum` of trap codes with no extra information. This commit is doubly-motivated by the desire to always use the new `BacktraceContext` type instead of sometimes using that and sometimes using `Trap`. Most of the changes here were around updating `Trap::new` calls to `bail!` calls instead. Tests which assert particular error messages additionally often needed to use the `:?` formatter instead of the `{}` formatter because the prior formats the whole `anyhow::Error` and the latter only formats the top-most error, which now contains the backtrace. * Merge `Trap` and `TrapCode` With prior refactorings there's no more need for `Trap` to be opaque or otherwise contain a backtrace. This commit parse down `Trap` to simply an `enum` which was the old `TrapCode`. All various tests and such were updated to handle this. The main consequence of this commit is that all errors have a `BacktraceContext` context attached to them. This unfortunately means that the backtrace is printed first before the error message or trap code, but given all the prior simplifications that seems worth it at this time. * Rename `BacktraceContext` to `WasmBacktrace` This feels like a better name given how this has turned out, and additionally this commit removes having both `WasmBacktrace` and `BacktraceContext`. * Soup up documentation for errors and traps * Fix build of the C API Co-authored-by: Pat Hickey List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/diff_wasmtime.rs