Files

Nick Fitzgerald ec47335b9c wasmtime: Add a Config::native_unwind_info method (#4643 )

This method configures whether native unwind information (e.g. `.eh_frame` on
Linux) is generated or not.

This helps integrate with third-party stack capturing tools, such as the system
unwinder or the `backtrace` crate. It does not affect whether Wasmtime can
capture stack traces in Wasm code that it is running or not.

Unwind info is always enabled on Windows, since the Windows ABI requires it.

This configuration option defaults to true.

Additionally, we deprecate `Config::wasm_backtrace` since we can always cheaply
capture stack traces ever since
https://github.com/bytecodealliance/wasmtime/pull/4431.

Fixes https://github.com/bytecodealliance/wasmtime/issues/4554

2022-08-08 13:54:51 -07:00

src

wasmtime: Add a Config::native_unwind_info method (#4643 )

2022-08-08 13:54:51 -07:00

wasm-spec-interpreter

Add *.wast support for invoking components (#4526 )

2022-07-27 21:02:16 +00:00

build.rs

Actually make spectest fuzzing deterministic

2021-03-29 09:12:16 -07:00

Cargo.toml

implement fuzzing for component types (#4537 )

2022-08-04 12:02:55 -05:00

README.md

Create a new wasmtime-fuzzing crate

2019-11-21 14:51:07 -08:00

README.md

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.