bbdea06e2d
This PR adds a new fuzz target, `differential_wasmi`, that runs a Cranelift-based Wasm backend alongside a simple third-party Wasm interpeter crate (`wasmi`). The fuzzing runs the first function in a given module to completion on each side, and then diffs the return value and linear memory contents. This strategy should provide end-to-end coverage including both the Wasm translation to CLIF (which has seen some subtle and scary bugs at times), the lowering from CLIF to VCode, the register allocation, and the final code emission. This PR also adds a feature `experimental_x64` to the fuzzing crate (and the chain of dependencies down to `cranelift-codegen`) so that we can fuzz the new x86-64 backend as well as the current one.
Fuzzing Infrastructure for Wasmtime
This crate provides test case generators and oracles for use with fuzzing.
These generators and oracles are generally independent of the fuzzing engine
that might be using them and driving the whole fuzzing process (e.g. libFuzzer
or AFL). As such, this crate does not contain any actual fuzz targets
itself. Those are generally just a couple lines of glue code that plug raw input
from (for example) libFuzzer into a generator, and then run one or more
oracles on the generated test case.
If you're looking for the actual fuzz target definitions we currently have, they
live in wasmtime/fuzz/fuzz_targets/* and are driven by cargo fuzz and
libFuzzer.