diff options
author | Alon Zakai <azakai@google.com> | 2020-04-22 12:11:46 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2020-04-22 12:11:46 -0700 |
commit | 35a36b15e1bf16b78a6f3e174543681748295e81 (patch) | |
tree | 1a5dd5af79b064b73c9475948f077cdc93f47e49 /src/parsing.h | |
parent | d8b414d22b032efc87dbceb50abef8bce5ce8266 (diff) | |
download | binaryen-35a36b15e1bf16b78a6f3e174543681748295e81.tar.gz binaryen-35a36b15e1bf16b78a6f3e174543681748295e81.tar.bz2 binaryen-35a36b15e1bf16b78a6f3e174543681748295e81.zip |
[fuzzing] wasm2c integration (#2772)
This adds support for fuzzing with wabt's wasm2c that @binji wrote.
Basically we compile the wasm to C, then compile the C to a native
executable with a custom main() to wrap around it. The executable
should then print exactly the same as that wasm when run in either
the binaryen interpreter or in a JS VM with our wrapper JS for that
wasm. In other words, compiling the wasm to C is another way to
run that wasm.
The main reasons I want this are to fuzz wasm2c itself, and to
have another option for fuzzing emcc. For the latter, we do fuzz
wasm-opt quite a lot, but that doesn't fuzz the non-wasm-opt
parts of emcc. And using wasm2c for that is nice since the
starting point is always a wasm file, which means we
can use tools like wasm-reduce and so forth, which can be
integrated with this fuzzer.
This also:
Refactors the fuzzer harness a little to make it easier to
add more "VMs" to run wasms in.
Do not autoreduce when re-running a testcase, which I hit
while developing this.
Diffstat (limited to 'src/parsing.h')
0 files changed, 0 insertions, 0 deletions