I followed the same testing approach when writing a Wasm binary parser (technically, a decoder)[0].
It was pretty helpful having the official spec suite available and a major boost of confidence that your parser is compliant.
Nevertheless, it was my own tests that found a regression in the latest published version of the spec[1], which shows how important it is to have a variety of implementations.
Note that I had to switch the harness from wazero to Node (unfortunately!) when it turned out wazero doesn't support gc and other new proposals (e.g. your comment here https://github.com/wazero/wazero/issues/2483)
Thank you very much for maintaining wazero - I love that project, and am looking forward to being able to use it for this in the future.
evacchi does most of the maintaining these days, but I'll keep helping as best as I can.
Your harness looks interesting to replace wast2json with watgo in wasm2go. Though my current problem is that I should be using the JSON to decide which tests to run (manual process so far), and to generate the more complicated test files (e.g. the ones that link modules together).
This is a really interesting project. The ability to inspect and manipulate Wasm modules at runtime opens up a lot of possibilities for debugging and tooling. Curious whether you've benchmarked the overhead of the toolkit itself on larger Go-compiled Wasm binaries?
I followed the same testing approach when writing a Wasm binary parser (technically, a decoder)[0].
It was pretty helpful having the official spec suite available and a major boost of confidence that your parser is compliant.
Nevertheless, it was my own tests that found a regression in the latest published version of the spec[1], which shows how important it is to have a variety of implementations.
[0] https://github.com/agis/wadec
[1] https://github.com/WebAssembly/spec/issues/2066
I need to check their harness, compare it to wazero's and my own (wasm2go)
Btw, if Eli reads this: thanks for the WAT samples, they were very helpful working on wasm2go!
You're welcome :)
The harnesses are documented here: https://github.com/eliben/watgo/tree/main/tests
Note that I had to switch the harness from wazero to Node (unfortunately!) when it turned out wazero doesn't support gc and other new proposals (e.g. your comment here https://github.com/wazero/wazero/issues/2483)
Thank you very much for maintaining wazero - I love that project, and am looking forward to being able to use it for this in the future.
You're welcome :)
evacchi does most of the maintaining these days, but I'll keep helping as best as I can.
Your harness looks interesting to replace wast2json with watgo in wasm2go. Though my current problem is that I should be using the JSON to decide which tests to run (manual process so far), and to generate the more complicated test files (e.g. the ones that link modules together).
I'm working on EH right now! Slowly walking towards GC!!
This is a really interesting project. The ability to inspect and manipulate Wasm modules at runtime opens up a lot of possibilities for debugging and tooling. Curious whether you've benchmarked the overhead of the toolkit itself on larger Go-compiled Wasm binaries?
This looks really useful for pre-runtime inspection of WASM modules. Are you using it for any security or sandboxing use cases?