xujuntwt95329 wrote: > > Hi @mh4ck-Thales this is caused by [#77949 > > (comment)](https://github.com/llvm/llvm-project/pull/77949#discussion_r1463458728), > > currently we need to modify it manually. > > Thanks! That did the trick for the breakpoint and disassembly problems. When > using `read register` I can only see `pc` and nothing else though. I'm not > sure assimilating Wasm variables to registers is the good way to go anyway, > because the number of Wasm variables is not fixed in advance, and subject to > the context of execution (with local variables). This is not the case at all > for classic CPU registers, and I'm not sure the generic code managing > registers in lldb will support that. Using a solution like @jimingham > proposed with subcommands of `language wasm` may be a easier, less bug prone > way to implement this.
Yes, the `virtual register` concepts is just used internally to allow us to process wasm locals/globals/operand stack values in a plugin without a huge modification to LLDB core part. This allows users to debug their source code, but doesn't support reading specific local/global values. Currently lldb doesn't have an exist model for representing wasm's local/global/operand stack values, I think encoding them as virtual registers is an easy approach for enabling WebAssembly debugging and without a huge modification to LLDB core part. On the other hand, as a managed language, I think most people won't need to read specific local/global of an instance, just like most of the JavaScript developer won't care about the value of a register in V8 during debugging, they just care about the value of their variables. So I think the virtual register approach should be okay for the developer usage, with small engineering effort and limited quality influence to LLDB. 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
