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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
