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

[Xu Jun via lldb-commits]

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