paolosevMSFT 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>` https://github.com/llvm/llvm-project/pull/77949 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
