Changes in dummy.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/dummy.rs

874da677 - Fix `MemoryType::default_value` with shared memories (#12029)

Fri, 14 Nov 2025 18:37:59 +0000

Fix `MemoryType::default_value` with shared memories (#12029)* Fix `MemoryType::default_value` with shared memoriesThis fixes fallout from #12022 which was detected during fuzzing whichtried creating a shared memory.* Fix tests List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

5279f5c3 - Don't discard errors in `default_value` helpers (#10584)

Tue, 15 Apr 2025 16:06:14 +0000

Don't discard errors in `default_value` helpers (#10584)This commit updates the `default_value` helpers added recently to returna `Result` instead of returning an `Option` and throwing away errorinformation. This fixes a fuzz bug showing up recently which happenedbecause the error in question was one we've flagged to ignore, butbecause the error was discarded we didn't know to ignore it so it endedup causing a fuzz failure. List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

df4cb6eb - Expose default value constructors for Wasm types in host API (#10500)

Wed, 02 Apr 2025 14:36:37 +0000

Expose default value constructors for Wasm types in host API (#10500)* Expose default value constructors for Wasm types in host API* Added doc comments List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

0b4c754a - Exception and control tags (#10251)

Thu, 20 Feb 2025 15:49:20 +0000

Exception and control tags (#10251)* Tags* Tag tests* Tests* Refer to tags issue* Engine index* Simplify* Fix clippy warnings List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

288c1513 - Shared memory support (#9507)

Fri, 01 Nov 2024 01:33:39 +0000

Shared memory support (#9507)* Trying to add shared memory :)* Adding initial support for shared memory in the memory type andthe C-API* Fixing dummies* Remving the SharedMemory(CMemoryType) variant from the wasm_extern_* types* Removing ExternType::SharedMemory as well! Not needed.* * Using MemoryTypeBuilder as suggested.* moving dummy shared memory* Fixing clang format errors* Try again to appease clang-format---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

0c0153c1 - Enforce `clippy::clone_on_copy` for the workspace (#9025)

Sat, 27 Jul 2024 01:11:06 +0000

Enforce `clippy::clone_on_copy` for the workspace (#9025)* Derive `Copy` for `Val`* Fix `clippy::clone_on_copy` for the whole repo* Enforce `clippy::clone_on_copy` for the workspace* fix some more clippy::clone_on_copy that got missed List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

f676c176 - Enable rustc's `unused-lifetimes` lint (#8711)

Thu, 30 May 2024 19:37:58 +0000

Enable rustc's `unused-lifetimes` lint (#8711)* Enable rustc's `unused-lifetimes` lintThis is allow-by-default doesn't seem to have any false positives inWasmtime's codebase so enable it by default to help clean up vestiges ofold refactorings.* Remove another unused lifetime* Remove another unused lifetime List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

62329048 - Add the `Ref::null` constructor and use it in a few places (#8492)

Sat, 27 Apr 2024 06:16:30 +0000

Add the `Ref::null` constructor and use it in a few places (#8492)Just a small follow up to https://github.com/bytecodealliance/wasmtime/pull/8481 List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

dd70e31d - wasmtime(gc): Add support for array types (#8481)

Fri, 26 Apr 2024 16:44:31 +0000

wasmtime(gc): Add support for array types (#8481)This commit adds support for defining array types from Wasm or the host, andmanaging them inside the engine's types registry. It does not introduce supportfor allocating or manipulating array values. That functionality will come infuture pull requests. List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

960187e3 - Rename `Concrete` to `ConcreteFunc`; introduce `WasmSubType` and `WasmCompositeType` (#8465)

Wed, 24 Apr 2024 21:22:47 +0000

Rename `Concrete` to `ConcreteFunc`; introduce `WasmSubType` and `WasmCompositeType` (#8465)* Rename `WasmHeapType::Concrete(_)` to `WasmHeapType::ConcreteFunc(_)`* Rename `wasmtime::HeapType::Concrete` to `wasmtime::HeapType::ConcreteFunc`* Introduce Wasm sub- and composite-typesRight now, these are only ever final function types that don't have a supertype,but this refactoring paves the way for array and struct types, and lets us makesure that `match`es are exhaustive for when we add new enum variants. (AlthoughI did add an `unwrap_func` helper for use when it is clear that the type shouldbe a function type, and if it isn't then we should panic.) List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.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/dummy.rs

9ce3ffe1 - Update some CI dependencies (#7983)

Thu, 22 Feb 2024 23:54:03 +0000

Update some CI dependencies (#7983)* Update some CI dependencies* Update to the latest nightly toolchain* Update mdbook* Update QEMU for cross-compiled testing* Update `cargo nextest` for usage with MIRIprtest:full* Remove lots of unnecessary imports* Downgrade qemu as 8.2.1 seems to segfault* Remove more imports* Remove unused winch trait method* Fix warnings about unused trait methods* More unused imports* More unused imports List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.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/dummy.rs

8652011f - Refactor `wasmtime::FuncType` to hold a handle to its registered type (#7892)

Fri, 09 Feb 2024 21:07:52 +0000

Refactor `wasmtime::FuncType` to hold a handle to its registered type (#7892)* Refactor `wasmtime::FuncType` to hold a handle to its registered typeRather than holding a copy of the type directly, it now holds a `RegisteredType`which internally is* A `VMSharedTypeIndex` pointing into the engine's types registry.* An `Arc` handle to the engine's type registry.* An `Arc` handle to the actual type.The last exists only to keep it so that accessing a `wasmtime::FuncType`'sparameters and results fast, avoiding any new locking on call hot paths.This is helping set the stage for further types and `TypeRegistry` refactorsneeded for Wasm GC.* Update the C API for the function types refactorprtest:full* rustfmt* Fix benches build List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.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/dummy.rs

63d80fc5 - Remove the need to have a `Store` for an `InstancePre` (#5683)

Thu, 02 Feb 2023 17:54:20 +0000

Remove the need to have a `Store` for an `InstancePre` (#5683)* Remove the need to have a `Store` for an `InstancePre` This commit relaxes a requirement of the `InstancePre` API, notably its construction via `Linker::instantiate_pre`. Previously this function required a `Store` to be present to be able to perform type-checking on the contents of the linker, and now this requirement has been removed. Items stored within a linker are either a `HostFunc`, which has type information inside of it, or an `Extern`, which doesn't have type information inside of it. Due to the usage of `Extern` this is why a `Store` was required during the `InstancePre` construction process, it's used to extract the type of an `Extern`. This commit implements a solution where the type information of an `Extern` is stored alongside the `Extern` itself, meaning that the `InstancePre` construction process no longer requires a `Store`. One caveat of this implementation is that some items, such as tables and memories, technically have a "dynamic type" where during type checking their current size is consulted to match against the minimum size required of an import. This no longer works when using `Linker::instantiate_pre` as the current size used is the one when it was inserted into the linker rather than the one available at instantiation time. It's hoped, however, that this is a relatively esoteric use case that doesn't impact many real-world users. Additionally note that this is an API-breaking change. Not only is the `Store` argument removed from `Linker::instantiate_pre`, but some other methods such as `Linker::define` grew a `Store` argument as the type needs to be extracted when an item is inserted into a linker. Closes #5675 * Fix the C API * Fix benchmark compilation * Add C API docs * Update crates/wasmtime/src/linker.rs Co-authored-by: Andrew Brown --------- Co-authored-by: Andrew Brown List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

76b82910 - Remove the module linking implementation in Wasmtime (#3958)

Wed, 23 Mar 2022 19:57:34 +0000

Remove the module linking implementation in Wasmtime (#3958)* Remove the module linking implementation in Wasmtime This commit removes the experimental implementation of the module linking WebAssembly proposal from Wasmtime. The module linking is no longer intended for core WebAssembly but is instead incorporated into the component model now at this point. This means that very large parts of Wasmtime's implementation of module linking are no longer applicable and would change greatly with an implementation of the component model. The main purpose of this is to remove Wasmtime's reliance on the support for module-linking in `wasmparser` and tooling crates. With this reliance removed we can move over to the `component-model` branch of `wasmparser` and use the updated support for the component model. Additionally given the trajectory of the component model proposal the embedding API of Wasmtime will not look like what it looks like today for WebAssembly. For example the core wasm `Instance` will not change and instead a `Component` is likely to be added instead. Some more rationale for this is in #3941, but the basic idea is that I feel that it's not going to be viable to develop support for the component model on a non-`main` branch of Wasmtime. Additionaly I don't think it's viable, for the same reasons as `wasm-tools`, to support the old module linking proposal and the new component model at the same time. This commit takes a moment to not only delete the existing module linking implementation but some abstractions are also simplified. For example module serialization is a bit simpler that there's only one module. Additionally instantiation is much simpler since the only initializer we have to deal with are imports and nothing else. Closes #3941 * Fix doc link * Update comments List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

e68aa995 - Implement the memory64 proposal in Wasmtime (#3153)

Thu, 12 Aug 2021 14:40:20 +0000

Implement the memory64 proposal in Wasmtime (#3153)* Implement the memory64 proposal in Wasmtime This commit implements the WebAssembly [memory64 proposal][proposal] in both Wasmtime and Cranelift. In terms of work done Cranelift ended up needing very little work here since most of it was already prepared for 64-bit memories at one point or another. Most of the work in Wasmtime is largely refactoring, changing a bunch of `u32` values to something else. A number of internal and public interfaces are changing as a result of this commit, for example: * Acessors on `wasmtime::Memory` that work with pages now all return `u64` unconditionally rather than `u32`. This makes it possible to accommodate 64-bit memories with this API, but we may also want to consider `usize` here at some point since the host can't grow past `usize`-limited pages anyway. * The `wasmtime::Limits` structure is removed in favor of minimum/maximum methods on table/memory types. * Many libcall intrinsics called by jit code now unconditionally take `u64` arguments instead of `u32`. Return values are `usize`, however, since the return value, if successful, is always bounded by host memory while arguments can come from any guest. * The `heap_addr` clif instruction now takes a 64-bit offset argument instead of a 32-bit one. It turns out that the legalization of `heap_addr` already worked with 64-bit offsets, so this change was fairly trivial to make. * The runtime implementation of mmap-based linear memories has changed to largely work in `usize` quantities in its API and in bytes instead of pages. This simplifies various aspects and reflects that mmap-memories are always bound by `usize` since that's what the host is using to address things, and additionally most calculations care about bytes rather than pages except for the very edge where we're going to/from wasm. Overall I've tried to minimize the amount of `as` casts as possible, using checked `try_from` and checked arithemtic with either error handling or explicit `unwrap()` calls to tell us about bugs in the future. Most locations have relatively obvious things to do with various implications on various hosts, and I think they should all be roughly of the right shape but time will tell. I mostly relied on the compiler complaining that various types weren't aligned to figure out type-casting, and I manually audited some of the more obvious locations. I suspect we have a number of hidden locations that will panic on 32-bit hosts if 64-bit modules try to run there, but otherwise I think we should be generally ok (famous last words). In any case I wouldn't want to enable this by default naturally until we've fuzzed it for some time. In terms of the actual underlying implementation, no one should expect memory64 to be all that fast. Right now it's implemented with "dynamic" heaps which have a few consequences: * All memory accesses are bounds-checked. I'm not sure how aggressively Cranelift tries to optimize out bounds checks, but I suspect not a ton since we haven't stressed this much historically. * Heaps are always precisely sized. This means that every call to `memory.grow` will incur a `memcpy` of memory from the old heap to the new. We probably want to at least look into `mremap` on Linux and otherwise try to implement schemes where dynamic heaps have some reserved pages to grow into to help amortize the cost of `memory.grow`. The memory64 spec test suite is scheduled to now run on CI, but as with all the other spec test suites it's really not all that comprehensive. I've tried adding more tests for basic things as I've had to implement guards for them, but I wouldn't really consider the testing adequate from just this PR itself. I did try to take care in one test to actually allocate a 4gb+ heap and then avoid running that in the pooling allocator or in emulation because otherwise that may fail or take excessively long. [proposal]: https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md * Fix some tests * More test fixes * Fix wasmtime tests * Fix doctests * Revert to 32-bit immediate offsets in `heap_addr` This commit updates the generation of addresses in wasm code to always use 32-bit offsets for `heap_addr`, and if the calculated offset is bigger than 32-bits we emit a manual add with an overflow check. * Disable memory64 for spectest fuzzing * Fix wrong offset being added to heap addr * More comments! * Clarify bytes/pages List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs

bb85366a - Enable simd fuzzing on oss-fuzz (#3152)

Thu, 05 Aug 2021 21:24:42 +0000

Enable simd fuzzing on oss-fuzz (#3152)* Enable simd fuzzing on oss-fuzz This commit generally enables the simd feature while fuzzing, which should affect almost all fuzzers. For fuzzers that just throw random data at the wall and see what sticks, this means that they'll now be able to throw simd-shaped data at the wall and have it stick. For wasm-smith-based fuzzers this commit also updates wasm-smith to 0.6.0 which allows further configuring the `SwarmConfig` after generation, notably allowing `instantiate-swarm` to generate modules using simd using `wasm-smith`. This should much more reliably feed simd-related things into the fuzzers. Finally, this commit updates wasmtime to avoid usage of the general `wasm_smith::Module` generator to instead use a Wasmtime-specific custom default configuration which enables various features we have implemented. * Allow dummy table creation to fail Tables might creation for imports may exceed the memory limit on the store, which we'll want to gracefully recover from and not fail the fuzzers. List of files: /wasmtime-44.0.1/crates/fuzzing/src/oracles/dummy.rs