github-actions[bot] commented on issue #5502:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "cranelift", "fuzzing"Thus the following users have been cc'd because of the following labels:
- fitzgen: fuzzing
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
jameysharp commented on issue #5502:
@uweigand, FYI: This PR illustrates what we need to start routinely fuzz-testing additional Cranelift backends. I'd love to start testing s390x on our OSS-Fuzz quota too. For non-x86, OSS-Fuzz can only test that codegen succeeds, not that the generated code runs correctly, but I expect that to be enough to catch many bugs. Of particular interest right now, this should help us catch non-SSA lowerings.
The steps are:
- add the
s390x
feature to thecranelift-codegen
dependency infuzz/Cargo.toml
(optionally, you can temporarily remove the other backends there to focus on that one)- run
cargo +nightly fuzz run cranelift-icache
on any host, and/orcargo +nightly fuzz run cranelift-fuzzgen
on an s390x host—whichever you have more CPU cycles available on- as it finds bugs, add backend-specific exceptions for known issues with lowering particular instructions at particular types, as illustrated by this PR
Once the fuzzer runs for an hour without finding new bugs it's probably ready.
These fuzz targets don't yet generate all possible Cranelift instructions, so you won't have to write down exceptions for every unimplemented thing. It's currently limited to scalar types and arithmetic/load/store operations mostly, but we're incrementally expanding coverage.
uweigand commented on issue #5502:
@jameysharp s390x support PR now posted here: https://github.com/bytecodealliance/wasmtime/pull/5596
Thanks for pointing this out!
Last updated: Dec 23 2024 at 12:05 UTC