bytecodealliance
threads: fuzz `shared-everything-threads`
This adds initial support for fuzzing the WebAssembly side of the shared-everything-threads proposal. Eventual addition of the CM builtins will require extensions to this.
At this stage (after df11990) the fuzzer will trigger an unimplemented! failure here:
$ cargo +nightly fuzz run run
...
thread '<unnamed>' panicked at crates/wasm-mutate/src/module.rs:46:18:
not implemented
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
It is unclear to me why this hasn't been triggered previously: shouldn't occasionally enabling GC have triggered this failure due to
https://github.com/bytecodealliance/wasm-tools/blob/8c3346e72d3f5100ed80db2e44e326873a9d2443/crates/wasm-smith/src/core.rs#L1052-L1058
@fitzgen, as I revisited this PR, I realized that I wanted to add several missing bits as well as split several of the commits into separate PRs. Since I've substantially changed the PR, let's forget about the previous review, though I do believe I've addressed the comments you made.
This PR is currently in an intermediate state and I could use some help figuring out what to do: I could (a) just continue hacking away at this until fuzzing "fully works" but that might take a while due to the large amount of reverse validation I have to add to wasm-smith (i.e., many instructions generate invalid parameters in a shared function context). Another option is to (b) just cordon off the ability to create shared function bodies for now; this would allow generating all the types and what not and for that to be fuzzed while I work on (a). Opinions?
That last commit, a17f4f4, is a half-hearted attempt to avoid fuzz errors when fuzzing locally and will go away.
This PR is currently in an intermediate state and I could use some help figuring out what to do: I could (a) just continue hacking away at this until fuzzing "fully works" but that might take a while due to the large amount of reverse validation I have to add to wasm-smith (i.e., many instructions generate invalid parameters in a shared function context). Another option is to (b) just cordon off the ability to create shared function bodies for now; this would allow generating all the types and what not and for that to be fuzzed while I work on (a). Opinions?
I'm all for landing incremental progress, so long as the parts that are landing are working. We don't need to take an all-or-nothing approach to adding support for generating new wasm proposals in wasm-smith.
Ok, I've removed the last commit and added others that allow this to reach at least 200K fuzz iterations locally. This PR still does not generate shared function bodies but some of the plumbing is now in place at least. The latest fuzz failure happens in the wasm-mutate: a shared function type used by a ref.func const expression in a shared table initializer gets mutated into an unshared function type, resulting in a validation error. Not sure yet how to fix that (where does that get mutated?) but that should anecdotally explain where this PR is at. I suspect there are more things like this hidden away that fuzzing will find; it may be time to let oss-fuzz start finding them?
One thing I've started to worry about in wasm-smith is generation speed. I'm not sure what effect this PR has on the number of fuzz executions per second, but I don't like all the added ...map().filter()... logic to get at the shared or unshared sides of the world. I've been wondering: how about a new level of indirection on Module, like funcs: struct { shared: ..., unshared: ... }? In other words, should we track the shared and unshared things separately to avoid having to iterate and filter each time we generate something? I think this worry could become even more worrisome in code_builder.rs: we will need to quite frequently search through either the shared or unshared things depending on whether we're in a shared context or not.