|
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, v40.0.0 |
|
| #
fee9be21 |
| 09-Dec-2025 |
Alex Crichton <[email protected]> |
Add a new fuzzer focused on component-model-async events (#12119)
* Add a new fuzzer focused on component-model-async events
This commit adds a new fuzzer mode to the `misc` fuzzer of Wasmtime whic
Add a new fuzzer focused on component-model-async events (#12119)
* Add a new fuzzer focused on component-model-async events
This commit adds a new fuzzer mode to the `misc` fuzzer of Wasmtime which is focused on async events and interleavings of components using the component-model-async proposal. This fuzzer works by having a precompiled guest program which serves as the component to run. This precompiled component has a custom `fuzz.wit` which is used to interface with the fuzzer itself. The fuzzer is then a fuzz-generated sequence of commands to send to the component which verifies that everything executes correctly, has no panics, etc.
This fuzzer intends to stress async communication and task infrastructure with component-model-async. Notably this does not stress lifting/lowering or arbitrary type signatures. This does, however, permute all of the following:
* Guest/host interactions (also guest/guest, host/host, etc). * Async functions, both ready and pending. * Future operations: reads, writes, cancellation, transfers, etc. * Stream operations: reads, writes, cancellation, transfers, etc.
This is all throwing into a large "soup" and then asserted to work correctly. There's a few gotchas here and there for how this fuzzer is designed, such as some events requiring "yield N times to await this event happening". This is required because Wasmtime is allowed to non-deterministically select between a number of "ready events" and what to dispatch.
This is not intended to be a one-size-fits-all fuzzer for component-model-async. The recent enhancements to the `component_api` fuzzer are intended to complement this fuzzer in terms of what's stressed where internally.
* Review comments
show more ...
|
|
Revision tags: 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 |
|
| #
6047d27e |
| 28-Jul-2025 |
Khagan (Khan) Karimov <[email protected]> |
Add fuzzer integration for gc/mutatis (#11290)
* Add fuzzer integration for gc/mutatis
* Replace bincode with postcard. Inline fuzz_mutate. Address other small comments
* Update Cargo.lock after r
Add fuzzer integration for gc/mutatis (#11290)
* Add fuzzer integration for gc/mutatis
* Replace bincode with postcard. Inline fuzz_mutate. Address other small comments
* Update Cargo.lock after rebase
* Update rng.gen to rng.fill to avoid deprecation failure
* Remove table_ops from misc. Update fuzz_target. Keep Arbitrary impl it gives some dependecy error. Will be addressed later
* Update Cargo.lock to match upstream/main
* Regenerate Cargo.lock after rebase and dependency changes
* Reset Cargo.lock to upstream/main to preserve cargo-deny compatibility
* Update dependencies
---------
Co-authored-by: Khagan Karimov <[email protected]>
show more ...
|
|
Revision tags: 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 |
|
| #
94ec88ea |
| 08-Apr-2025 |
Chris Fallin <[email protected]> |
Cranelift: initial try_call / try_call_indirect (exception) support. (#10510)
* Cranelift: initial try_call / try_call_indirect (exception) support.
This PR adds `try_call` and `try_call_indirect`
Cranelift: initial try_call / try_call_indirect (exception) support. (#10510)
* Cranelift: initial try_call / try_call_indirect (exception) support.
This PR adds `try_call` and `try_call_indirect` instructions, and lowerings on four of five ISAs (x86-64, aarch64, riscv64, pulley; s390x has its own non-shared ABI code that will need separate work).
It extends CLIF to support these instructions as new kinds of branches, and extends block-calls to accept `retN` and `exnN` block-call args that carry the normal return values or exception payloads (respectively) into the appropriate successor blocks.
It wires up the "normal return path" so that it continues to work. It updates the ABI so that unwinding is possible without an initial register state at throw: specifically, as per our RFC, all registers are clobbered. It also includes metadata in the `MachBuffer` that describes exception-catch destinations. However, no unwinder exists to interpret these catch-destinations yet, so they are untested.
* Add try_call_indirect lowering as well.
show more ...
|
|
Revision tags: v31.0.0 |
|
| #
1ea710d6 |
| 14-Mar-2025 |
Andrew Brown <[email protected]> |
asm: fuzz `cranelift-codegen-x64` in the `misc` target (#10403)
As discussed previously, this change adds fuzzing for the x64 assembler to the melting pot target, `misc`, in order to get at least so
asm: fuzz `cranelift-codegen-x64` in the `misc` target (#10403)
As discussed previously, this change adds fuzzing for the x64 assembler to the melting pot target, `misc`, in order to get at least some fuzzing cycles on OSS-Fuzz.
show more ...
|
| #
840f5448 |
| 12-Mar-2025 |
Alex Crichton <[email protected]> |
Consolidate some fuzzers into one (#10385)
This commit consolidates a number of fuzzers that we have in Wasmtime into a single fuzzer. This follows the pattern of [wasm-tools's `run` fuzzer][tools]
Consolidate some fuzzers into one (#10385)
This commit consolidates a number of fuzzers that we have in Wasmtime into a single fuzzer. This follows the pattern of [wasm-tools's `run` fuzzer][tools] where the first byte in the fuzz input says which fuzzer to run and then the rest of the input is the input to the fuzzer. This is intended to improve our time-slicing on OSS-Fuzz where less important fuzzers don't hog time from the "important fuzzers" such as `differential`. Some minor-ish fuzzers have been folded in to this new fuzzer, but we can also always move things around as needed
[tools]: https://github.com/bytecodealliance/wasm-tools/blob/main/fuzz/fuzz_targets/run.rs
show more ...
|