Debugging: add docs to describe how to perform guest debugging.#13097
Debugging: add docs to describe how to perform guest debugging.#13097cfallin merged 2 commits intobytecodealliance:mainfrom
Conversation
fitzgen
left a comment
There was a problem hiding this comment.
Doesn't necessarily have to be in this PR, but I think it would be fantastic to have two sections in this page:
- Using
lldbon the command line - Using VSCode as a graphical debugger
And then including screenshots in (2), similar to what we have for the guest profiler. Also (2) should probably come before (1) on the actual page.
Basically, I think this page could use some flash and pizazz (which screenshots and GUIs really help with) to show off all the great work you've done for guest debugging. As it is, this feels a little anti-climactic to me.
| 4. Run LLDB, connect and debug. | ||
|
|
||
| You'll need a recent version of LLDB (v32 or later) with Wasm | ||
| support enabled. The [wasi-sdk] distribution provides such a | ||
| build. | ||
|
|
||
| ```console | ||
| /opt/wasi-sdk/bin/lldb | ||
| (lldb) process connect --plugin wasm connect://0:1234 | ||
| Process 1 stopped | ||
| * thread #1, stop reason = signal SIGTRAP | ||
| frame #0: 0x00000000 | ||
| error: memory read failed for 0x0 | ||
| (lldb) b my_function | ||
| (lldb) continue | ||
| ``` | ||
|
|
||
| and use LLDB like normal, setting breakpoints, continuing and | ||
| stepping, examining memory and variable state, etc. |
There was a problem hiding this comment.
Maybe also show setting breakpoints, stepping, and printing variables? Ideally with some kind of actual bug in the Wasm program? I guess this requires using an actual wasm program for the example as well, instead of foo.wasm.
So maybe we have (a) the short+concise steps of setting up guest debugging (flags to enable and all that) and then (b) the slightly longer-form (but it really needn't actually be long, just longer) walkthrough that shows a real program and actually using the guest debugging support to diagnose a (very simple and obvious) bug in it.
Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
|
Thanks! I'll go ahead and merge this as-is (since it more or less mirrors what we have for native debugging) to have something for 44.0; and we can work on a longer intro/tutorial, maybe including VS Code etc, off the critical path. |
No description provided.