In bytecodealliance/rfcs#10, we have outlined a process by which we're
switching to a new compiler backend by default. The first step in this
process is to switch our fuzzing targets to use the new backend and wait
for any issues.
This PR adds the Cargo feature that enables the new backend in all
fuzzing targets.
In [Wasmtime](https://github.com/bytecodealliance/wasmtime), we're
planning to transition eventually to a new x86 backend. We recently
added a fuzz target for this backend that differentially fuzzes against
a Wasm interpreter.
This PR adds the new backend's fuzz target and adds a contact (me) to
the notification list.
Wasmtime uses
[regalloc.rs](https://github.com/bytecodealliance/regalloc.rs), a
register allocator written in Rust that was developed for use in
Cranelift (but is also an independently-usable crate). While it will be
indirectly fuzzed by wasmtime itself once we start fuzzing the new
backends that use it, we should also fuzz it directly, since it exposes
targets just for this. The regalloc fuzzing makes use of a symbolic
checker as an oracle for allocation results, so should be relatively
high-quality. This PR enables the `bt` (backtracking) allocator's fuzz
target, as this is the default allocator.
* Add wasm-tools repository to wasmtime project
This commit expands the fuzzers run under the Wasmtime project to
include those in the https://github.com/bytecodealliance/wasm-tools
repository. This includes various parsing for utilities used by Wasmtime
itself but also generally useful for other Rust projects! The
maintainers of the wasm-tools repository are also all currently all on
the notification list for Wasmtime fuzz bugs as well.
* Load all corpuses from wasmtime-libfuzzer-corpus
This is an attempt to apply the suggestions from #3316 to the fuzzing
infrastructure for the `wasmtime` target. This will hopefully allow the
delivery of SIGSEGV and SIGILL signals to the `wasmtime` program itself.
These are expected signals when executing wasm code so we don't want the
fuzzer to treat all forms of the signal as a fatal error.
This commit does for Rust code what the `CFLAGS` are configured to do
for C++ code, which is to enable debuginfo (but line tables only) as
well as forcing frame pointer generation to all assist in generating
stack traces.
This is an attempt to fixup the errors found on #3292. Although I'm not
certain where the error was coming from this switches the Rust
installation to being in `PATH` by default so there's no need to
`source` any scripts to get access to the Rust compiler.
Alex Crichton