Dakror opened Issue #2542:
<!-- Please try to describe precisely what you would like to do in
Cranelift/Wasmtime and/or expect from it. You can answer the questions below if
they're relevant and delete this text before submitting. Thanks for opening an
issue! -->Feature
<!-- What is the feature or code improvement you would like to do in
Cranelift/Wasmtime? -->As i understand the documentation, wasmtime offers debugging support using DWARF data embedded in wasm binaries.
However this cannot be used when writing / generating raw Webassembly or converting it via wat2wasm. It would therefore be a great feature to add wat-source-level debugging (much like the early Chrome DevTools debugging) to atleast look at the text representation.Benefit
<!-- What is the value of adding this in Cranelift/Wasmtime? -->
This would aid in debugging of immediate wasm code, where a high source representation is unavailable
Implementation
<!-- Do you have an implementation plan, and/or ideas for data structures or
algorithms to use? -->When using a wat2wasm parser or when generating an IR by yourself, you'd need to track the binary locations of your expressions to emit DWARF yourself
Alternatives
<!-- Have you considered alternative implementations? If so, how are they
better or worse than your proposal? -->I've also opened this issue over at binaryen, since this is what I'm using to generate raw WASM (via their C-API). However I think that this feature is generator independent and would best be implemented at the runtime.
yurydelendik commented on Issue #2542:
FWIW,
-g
generates DWARF info that uses wasm bytecode offset for source locations. See https://github.com/bytecodealliance/wasmtime/blob/main/tests/all/debug/simulate.rsThat's what Chrome and Firefox DevTools do, UI do the rest of the WAT magic.
yurydelendik commented on Issue #2542:
When using a wat2wasm parser or when generating an IR by yourself, you'd need to track the binary locations of your expressions to emit DWARF yourself
Looks like this is request for the wat2wasm tool(s) and not for wasmtime.
Dakror commented on Issue #2542:
FWIW,
-g
generates DWARF info that uses wasm bytecode offset for source locations. See https://github.com/bytecodealliance/wasmtime/blob/main/tests/all/debug/simulate.rsThat's what Chrome and Firefox DevTools do, UI do the rest of the WAT magic.
Where am i to specify
-g
? When compiling wasmtime from source? I don't quite understand. I'm using the Wasm C api + the wasmtime specific functions to embed wasmtime right now.
Dakror edited a comment on Issue #2542:
FWIW,
-g
generates DWARF info that uses wasm bytecode offset for source locations. See https://github.com/bytecodealliance/wasmtime/blob/main/tests/all/debug/simulate.rsThat's what Chrome and Firefox DevTools do, UI do the rest of the WAT magic.
Where am i to specify
-g
? When compiling wasmtime from source? I don't quite understand. I'm using the Wasm C api + the wasmtime specific functions to embed wasmtime right now, and im settingwasmtime_config_debug_info_set
to true.
Dakror commented on Issue #2542:
I've found that this is actually working and my tools werent properly set up. So the only thing that remains is the need for a UI / lookup for the code section offset into WAT code.
Dakror closed Issue #2542:
<!-- Please try to describe precisely what you would like to do in
Cranelift/Wasmtime and/or expect from it. You can answer the questions below if
they're relevant and delete this text before submitting. Thanks for opening an
issue! -->Feature
<!-- What is the feature or code improvement you would like to do in
Cranelift/Wasmtime? -->As i understand the documentation, wasmtime offers debugging support using DWARF data embedded in wasm binaries.
However this cannot be used when writing / generating raw Webassembly or converting it via wat2wasm. It would therefore be a great feature to add wat-source-level debugging (much like the early Chrome DevTools debugging) to atleast look at the text representation.Benefit
<!-- What is the value of adding this in Cranelift/Wasmtime? -->
This would aid in debugging of immediate wasm code, where a high source representation is unavailable
Implementation
<!-- Do you have an implementation plan, and/or ideas for data structures or
algorithms to use? -->When using a wat2wasm parser or when generating an IR by yourself, you'd need to track the binary locations of your expressions to emit DWARF yourself
Alternatives
<!-- Have you considered alternative implementations? If so, how are they
better or worse than your proposal? -->I've also opened this issue over at binaryen, since this is what I'm using to generate raw WASM (via their C-API). However I think that this feature is generator independent and would best be implemented at the runtime.
Last updated: Dec 23 2024 at 13:07 UTC