8 ms·

I happen to work on a lot of profiling and debugging tools and I’ve been wondering if the wasm spec has included anything about the “debugability” of wasm binar

by brancz 4y ago

I happen to work on a lot of profiling and debugging tools and I’ve been wondering if the wasm spec has included anything about the “debugability” of wasm binaries. After a quick scan of the table of contents I couldn’t find it but I’d be curious to hear from anyone who might know. I fear that with an explosion of wasm runtimes (this looks super cool but also I think the 4th or 5th wasm runtime I’ve noticed) that debugability will be a nightmare if it’s not in the spec.

lazyresearcher 4y ago
What features exactly are you looking for? I have only used emscripten but you can compile debug builds and step through the code in the browser's inspector.
- brancz 4y ago
  I don't know enough about wasm runtimes, but for example JIT runtimes like nodejs (or JVM via perf-map-agent [0]) allow writing out debug infos via the Linux Kernel JIT-Interface [1], which debuggers and profilers can then pick up to symbolize stack traces. Not saying that it has to be the Linux JIT perf-map interface, but it'd be nice if it's something implementors of the runtimes kept in mind (not implying that they're not, I just haven't read anything). [0] https://github.com/jvm-profiling-tools/perf-map-agent https://github.com/jvm-profiling-tools/perf-map-agent [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt https://github.com/torvalds/linux/blob/master/tools/perf/Doc...
  - miloignis 4y ago
    That looks similar to how I profile my webassembly in wasmtime: https://docs.wasmtime.dev/examples-profiling-perf.html https://docs.wasmtime.dev/examples-profiling-perf.html , so that might be what you're looking for! It works pretty well. 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 https://docs.wasmtime.dev/examples-debugging.html
abdusco 4y ago
Chrome has pretty good support for showing stack traces and debugging WASM binaries. https://developer.chrome.com/blog/new-in-devtools-91/#error-stack-traces https://developer.chrome.com/blog/new-in-devtools-91/#error-... See it in action: https://youtu.be/YqWEqYa-evk?t=828 https://youtu.be/YqWEqYa-evk?t=828
one-more-minute 4y ago
There's a proposed standard for embedding DWARF debug info in WASM binaries [1], which at least Chrome already supports. This is the same format native executables use, so it should put wasm ahead of other VMs in terms of source language independence. Dwarf seems to be the best thing we have, even if it's not renowned for its ease of use. [1] https://yurydelendik.github.io/webassembly-dwarf/ https://yurydelendik.github.io/webassembly-dwarf/
adrianfcole 4y ago
I'm a maintainer on wazero. We have two things in progress on debugability, though both are stalled as we complete the recently announced WebAssembly 2.0 draft spec (nearly done) [1]. 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 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 https://github.com/tetratelabs/wazero/issues/484 [2]: https://github.com/tetratelabs/wazero/issues/58 https://github.com/tetratelabs/wazero/issues/58 [3]: https://github.com/tetratelabs/wazero/blob/main/experimental/listener_test.go#L86-L90 https://github.com/tetratelabs/wazero/blob/main/experimental... [4]: https://github.com/tetratelabs/wazero/issues/451 https://github.com/tetratelabs/wazero/issues/451
quazar 4y ago
Webassembly has a very short reference implementation in OCaml, you can modify and inspect that easily. I did it for some projects.

by brancz 4y ago

lazyresearcher 4y ago

What features exactly are you looking for? I have only used emscripten but you can compile debug builds and step through the code in the browser's inspector.

brancz 4y ago
I don't know enough about wasm runtimes, but for example JIT runtimes like nodejs (or JVM via perf-map-agent [0]) allow writing out debug infos via the Linux Kernel JIT-Interface [1], which debuggers and profilers can then pick up to symbolize stack traces. Not saying that it has to be the Linux JIT perf-map interface, but it'd be nice if it's something implementors of the runtimes kept in mind (not implying that they're not, I just haven't read anything). [0] https://github.com/jvm-profiling-tools/perf-map-agent https://github.com/jvm-profiling-tools/perf-map-agent [1] https://github.com/torvalds/linux/blob/master/tools/perf/Documentation/jit-interface.txt https://github.com/torvalds/linux/blob/master/tools/perf/Doc...
- miloignis 4y ago
  That looks similar to how I profile my webassembly in wasmtime: https://docs.wasmtime.dev/examples-profiling-perf.html https://docs.wasmtime.dev/examples-profiling-perf.html , so that might be what you're looking for! It works pretty well. 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 https://docs.wasmtime.dev/examples-debugging.html

abdusco 4y ago

Chrome has pretty good support for showing stack traces and debugging WASM binaries. https://developer.chrome.com/blog/new-in-devtools-91/#error-stack-traces https://developer.chrome.com/blog/new-in-devtools-91/#error-... See it in action: https://youtu.be/YqWEqYa-evk?t=828 https://youtu.be/YqWEqYa-evk?t=828

one-more-minute 4y ago

There's a proposed standard for embedding DWARF debug info in WASM binaries [1], which at least Chrome already supports. This is the same format native executables use, so it should put wasm ahead of other VMs in terms of source language independence. Dwarf seems to be the best thing we have, even if it's not renowned for its ease of use. [1] https://yurydelendik.github.io/webassembly-dwarf/ https://yurydelendik.github.io/webassembly-dwarf/

adrianfcole 4y ago

I'm a maintainer on wazero. We have two things in progress on debugability, though both are stalled as we complete the recently announced WebAssembly 2.0 draft spec (nearly done) [1]. 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 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 https://github.com/tetratelabs/wazero/issues/484 [2]: https://github.com/tetratelabs/wazero/issues/58 https://github.com/tetratelabs/wazero/issues/58 [3]: https://github.com/tetratelabs/wazero/blob/main/experimental/listener_test.go#L86-L90 https://github.com/tetratelabs/wazero/blob/main/experimental... [4]: https://github.com/tetratelabs/wazero/issues/451 https://github.com/tetratelabs/wazero/issues/451

quazar 4y ago

Webassembly has a very short reference implementation in OCaml, you can modify and inspect that easily. I did it for some projects.