1. DWARF support - this requires those compiling to Wasm to configure to emit that. It is also murky because there's no canonical mapping in Wasm (most rely on LLVM underneath, but wazero is zero dependencies so we can't do that). Anyway, this is still on the table. [2]
2. Observability hooks - wazero is uniquely go-native which means we can do things like context propagation, allowing telemetry hooks including distributed tracing. While it may not seem intuitive to use that in Wasm, it can allow you to re-use tools that can show a trace graph. We have an experimental listener now, which has an example of how to make some strace looking logs. [3] Later, we'll convert this to an interceptor approach so that you can do metrics and stuff nicer. [4]
Regardless of this, debugging is easier because everything is in go. Apart from the DWARF thing which is totally important, the runtime being in Go completely means you debug everything going on, down to what is allocating memory, just by putting break-points in Go code. This is a very neat thing, and has helped some folks develop better code. Ex. https://github.com/inkeliz/karmem
Hope these help. Indeed the road to wasm is littered with a lot of runtimes, mostly abandoned or archived. We're hoping to buck the trend debugability, so watch the issues below if interested, and feel free to tell us anything we aren't doing right, too.
[1]: https://github.com/tetratelabs/wazero/issues/484 [2]: https://github.com/tetratelabs/wazero/issues/58 [3]: https://github.com/tetratelabs/wazero/blob/main/experimental... [4]: https://github.com/tetratelabs/wazero/issues/451
https://developer.chrome.com/blog/new-in-devtools-91/#error-...
See it in action:
[0] https://github.com/jvm-profiling-tools/perf-map-agent
[1] https://github.com/torvalds/linux/blob/master/tools/perf/Doc...
Wasmtime also has this page on debugging with supported debuggers when the webassembly was compiled with debug information: https://docs.wasmtime.dev/examples-debugging.html