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

[David Spickett via lldb-commits]

DavidSpickett wrote:

> What happens now is that there is a ProcessGDBRemote that registers for gdb-remote and it is returned by Process::FindPlugin. > Then there is the new ProcessWasm which might also register for the same gdb-remote maybe.
> But the problem is that at the moment when we start the connection we do not know that we are connecting to a Wasm target.
>
> Here, with the following call stack, target_sp->m_arch is still not initialized in Process::FindPlugin:

This feels like a bug or at least a design flaw in lldb then. ABI plugins for example clearly need to know the architecture and they work with remotes just fine, by reading the architecture from the object file (somehow).

But I'm not expecting you to address or even find that here, I would just prefer that this went ahead without the `wasm` top level command. If you still want to add that it can be a follow up where we can focus on that.

> 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.

We have some registers on Linux that could be considered part of the kernel interface not the hardware, so there is precedent for these "pseudo" registers. Examples are the memory tagging and scalable matrix control registers. However those features are enabled at kernel boot, so they don't come and go at runtime. Scalable vectors (SVE) can change *size* at runtime but they don't come and go either.

The one register that does that is the scalable matrix array register, which can be disabled by software. But, and this should tell you something, both I and my colleagues on GDB decided to just show it as all 0s when it's disabled. Instead of re-configuring the registers on every stop. It becomes hard to keep track when a register in the middle of the context disappears.

So I don't disagree with the concept of showing them as registers. They could be compared to the Linux kernel pseudo registers we have. However it will be more difficult than those registers, due to the dynamism. So if you're going to do it, please open a PR focused on that.

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