wasabi
wasabi copied to clipboard
danleh
Reduce analysis call overhead: use WebAssembly as analysis language, inline
- depends on multiple tables (GC/anyref proposal), multiple memories
- source language for analysis that can be compiled to WebAssembly: Rust? AssemblyScript?
- analysis API in that language?
I was looking for a tool that could help us to develop Wasm3, but it looks like our wasm interpreter could be useful for wasabi as well.
Can you elaborate a bit how Wasm3 (which is an interpreter for Wasm, right?) is useful for Wasabi?
wasm-interp is not used right now in Wasabi (Wasabi instruments purely statically, which is why I'm asking.)
That's interesting. So may I ask why wasabi described as "A dynamic analysis framework"? Perhaps you use different runtime for now. Also wasm-interp mentioned in README several times
The instrumentation is static, the analysis happens dynamically (but in the browser or Node.JS, since we assume a JavaScript host environment, which was the only type of host at the time of creation of Wasabi). More info: http://wasabi.software-lab.org/#how-does-it-work
wasm-interp is used once in the README, namely for running a very simple WebAssembly program (just to get people used to Wasm in general, not to Wasabi in particular).
Thank you for the clarification. It was just my guess, perhaps @vshymanskyy meant something another application.
@danleh yup. I also first thought that Wasm3 could help interpreting dynamically the generated analyzer, but after your comments in #23 I now it's not very different from passing the generated wasm file to the native (in-browser) wasm engine via some js glue code...
Wasm3 could itself be tweaked to output some human-friendly tracing information, however I think wasabi approach will be much faster at this.
Alright, for more comments/ideas on WASI support in Wasabi, let's stick to #23.