WAMR debugging improvements

[cimacmillan]

Summary

I've created this issue to track a few of the debugging improvements that we've planned to add, so that we can use it as a reference in PRs and close on any open decisions. We have merged some improvements into WAMR already, which are marked in the tasks, but the latter require a little more organisation.

Publish WAMR IDE vscode extension to marketplace

• What: Publish the WAMR IDE extension to VS Code marketplace on when release job is run
• Why: This saves the debugging engineer time finding WAMR IDE extension version & will automatically update it when a new version is created.
• How: There is a WAMR release step that bundles the VScode extension and uploads it to WAMR releases. This should be updated to also upload to the VS Code extension marketplace. There is a guide on publishing an extension through VSCode.

Add memory watchpoint control to WAMR IDE

• What: Add ability to set watchpoints in a WAMR IDE vscode debug session
• Why: This is a more user-friendly way of viewing and setting watchpoints vs the CLI
• How: Memory watchpoint support enabled in the debug interpreter, however we need to update the LLDB debug adapter so that VSCode can interface with it.

Add disassembly view to WAMR IDE

• What: Add ability to see disassembly of WASM in a WAMR IDE vscode debug session
• Why: This will allow a more fine grain view into what is actually being executed by WAMR, rather than the DWARF mapped code.
• How: It's possible to disassemble WAMR debug interpreter in CLI. This requires an update to the LLDB debug adapter WAMR IDE uses so that VSCode can interface with it.

Tasks

• Build macOS patched lldb in WAMR pipeline
• Install patched lldb on WAMR IDE vscode extension activation
• Add memory watchpoint support to classic interpreter
• Publish WAMR IDE vscode extension to marketplace
• Add memory watchpoint control to WAMR IDE
• Add disassembly view to WAMR IDE

[cimacmillan]

Our current plans are:

Publish WAMR IDE vscode extension to marketplace - @fadss is ready to make a contribution here. We think there is some discussion needed with WAMR maintainers about what destination we should be publishing the vscode extension to. I believe it may require a Microsoft account to be published.

Add memory watchpoint control to WAMR IDE & Add disassembly view to WAMR IDE - We have some changes ready for review. We're planning to push these to upstream LLVM & then pull the latest version into WAMR. For internal use in the meantime, we can build the WAMR IDE ext from a fork with a patch to enable them. If we get to the point of publishing the vscode extension to marketplace, and the LLVM contribution is still pending, we might request temporarily including the changes in the existing LLDB patch WAMR applies as part of the CI.

[loganek]

Thanks @cimacmillan

I believe it may require a Microsoft account to be published.

From what I see in the doc, we need azure devops account to generate personal access token. @xwang98 do you know if we already have WAMR account for that? Or should we discuss in the next TSC meeting how do we manage this (and I guess, in the future, similar) accounts, how to grant access etc.?

we can build the WAMR IDE ext from a fork
@cimacmillan where is the fork hosted?

Also, @wenyongh I remember there were some discussions about getting the patch for enabling WAMR debugging merged to LLVM; is there any progress on that? Should we chase LLDB maintainers to provide us with more specific feedback so we could possibly address it and merge it upstream?

[loganek]

Also, not sure if this should be done as part of this ticket or should we have another one for this, but I think it'd be great to support core dumps as they're defined here: WebAssembly/tool-conventions#195 @cimacmillan what's your opinion?

[cimacmillan]

@loganek Looks like a useful tool! I suppose this ticket is useful for general discussions about the work we have planned so don't mind including this here (& debugging WASI threads).

Or should we discuss in the next TSC meeting how do we manage this (and I guess, in the future, similar) accounts, how to grant access etc.?

Thanks for calling this out. Is there a regular meeting we can join to help close out that item?

[loganek]

Thanks for calling this out. Is there a regular meeting we can join to help close out that item?

I think you can propose a solution and if reasonable, we can implement it; otherwise, I can bring up the topic in the next TSC meeting (which happens monthlyish) and share the update.

[wenyongh]

Thanks @cimacmillan

I believe it may require a Microsoft account to be published.

From what I see in the doc, we need azure devops account to generate personal access token. @xwang98 do you know if we already have WAMR account for that? Or should we discuss in the next TSC meeting how do we manage this (and I guess, in the future, similar) accounts, how to grant access etc.?

we can build the WAMR IDE ext from a fork
@cimacmillan where is the fork hosted?

Also, @wenyongh I remember there were some discussions about getting the patch for enabling WAMR debugging merged to LLVM; is there any progress on that? Should we chase LLDB maintainers to provide us with more specific feedback so we could possibly address it and merge it upstream?

@loganek No any progress yet. We are trying to upgrade the toolkits (llvm, wasi-sdk, emsdk, wabt, etc.), I think we can upgrade llvm to version 15.0 and update the lldb patch accordingly: current lldb patch is based on llvm 13.0, maybe we can re-create the patch based on llvm 15.0 (and llvm main branch), and then try to make it upstream.
And yes, it would be great if the LLDB maintainers can provide us with more specific feedback so that we can address it.