Stream: git-wasmtime

Topic: wasmtime / Issue #2542 Debugging of Hand-Written WASM

Wasmtime GitHub notifications bot (Jan 04 2021 at 14:47):

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.

Wasmtime GitHub notifications bot (Jan 04 2021 at 18:34):

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

That's what Chrome and Firefox DevTools do, UI do the rest of the WAT magic.

Wasmtime GitHub notifications bot (Jan 04 2021 at 18:36):

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.

Wasmtime GitHub notifications bot (Jan 04 2021 at 21:11):

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

That'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.

Wasmtime GitHub notifications bot (Jan 04 2021 at 21:14):

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

That'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 setting wasmtime_config_debug_info_set to true.

Wasmtime GitHub notifications bot (Jan 04 2021 at 21:57):

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.

Wasmtime GitHub notifications bot (Jan 04 2021 at 21:57):

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: Nov 22 2024 at 16:03 UTC