[Lldb-commits] [lldb] [lldb] Implement WebAssembly debugging (PR #77949)

[Xu Jun via lldb-commits]

xujuntwt95329 wrote:

> > I see, thanks for the clarification. In the patch, the WasmLocal and WasmGlobal calls are done in ReadRegister, so it seems like those are being presented as register values? `register read` should show them. BTW, we shouldn't make a top level `wasm` command, we really try hard not to occupy more of the "easy to type" parts of the lldb command set than we can help, so there is lots left free for users to customize. There's a `language cplusplus` command (and on the swift fork `language swift`, so it would make sense to have wasm commands be vended as `language wasm`. Then people who do a lot of WebAssembly debugging can make an alias to wasm if that helps. Jim
> 
> However, `language` plugins do not seem to work for the Wasm case here. When we are debugging Wasm code, WebAssembly is the architecture and the source language is the whatever was compiled to Wasm, commonly C/C++ or Rust.
> 
> If we implement a `WasmLanguage` plugin we should override virtual methods like `bool IsTopLevelFunction(Function &function)`, `bool IsSourceFile(StringRef &file_path) `GetFormatters()` which do not really apply here.
> 
> But I agree that it is not nice to make a top level `wasm` command, so maybe the best way is to leave everything as it is and to just specify the plugin name at connection time: `process connect --plugin wasm connect://localhost:<PORT>`

Yes, the top level `wasm` command may be useful to WebAssembly users but may cause confusion to other users who doesn't use WebAssembly (Just like their isn't a top level `arm` command, `wasm` here should be conceptually equivalent with `arm`). Maybe we can remove this command from this PR, and users can add their own alias for convenience.

https://github.com/llvm/llvm-project/pull/77949