Reduce analysis call overhead: use WebAssembly as analysis language, inline

[danleh]

• 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?

[vshymanskyy]

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.

[danleh]

Can you elaborate a bit how Wasm3 (which is an interpreter for Wasm, right?) is useful for Wasabi?

[MaxGraey]

As wasm-interp replacement I guess 🤷️

[danleh]

wasm-interp is not used right now in Wasabi (Wasabi instruments purely statically, which is why I'm asking.)

[MaxGraey]

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

[danleh]

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).

[MaxGraey]

Thank you for the clarification. It was just my guess, perhaps @vshymanskyy meant something another application.

[vshymanskyy]

@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.

[danleh]

Alright, for more comments/ideas on WASI support in Wasabi, let's stick to #23.