Refine qWasmCallStack documentation

[MaxDesiatov]

qWasmCallStack documentation is not clear enough in how the list of PC values is delimited and the size of these values.

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Max Desiatov (MaxDesiatov)

Changes

qWasmCallStack is not clear if the list of PC values is delimited and the size of these values.

---

Full diff: https://github.com/llvm/llvm-project/pull/163803.diff

1 Files Affected:

• (modified) lldb/docs/resources/lldbgdbremote.md (+1-1)

diff --git a/lldb/docs/resources/lldbgdbremote.md b/lldb/docs/resources/lldbgdbremote.md
index f0c5e6b04d54c..e529ef48f1ce0 100644
--- a/lldb/docs/resources/lldbgdbremote.md
+++ b/lldb/docs/resources/lldbgdbremote.md
@@ -2491,7 +2491,7 @@ The packet below are supported by the
 ### qWasmCallStack
 
 Get the Wasm call stack for the given thread id. This returns a hex-encoded
-list of PC values, one for each frame of the call stack. To match the Wasm
+list (with no delimiters) of 64-bit PC values, one for each frame of the call stack. To match the Wasm
 specification, the addresses are encoded in little endian byte order, even if
 the endian of the Wasm runtime's host is not little endian.
 

[jasonmolenda]

Is it possible for there to be a 32-bit wasm implementation? I think "Wasm list (with no delimiters) of 64-bit PC values" is making it clear that we expect 8 bytes for each address, but I wasn't sure if it's trying to distinguish between a 64-bit and 32-bit environment.

[JDevlieghere]

Is it possible for there to be a 32-bit wasm implementation? I think "Wasm list (with no delimiters) of 64-bit PC values" is making it clear that we expect 8 bytes for each address, but I wasn't sure if it's trying to distinguish between a 64-bit and 32-bit environment.

Wasm started out being 32-bits only and that's what we've be targeting in LLDB. Only recently a proposal for 64-bit Wasm was approved.

[JDevlieghere]

LGTM modulo column limit/reflow

[DavidSpickett]

So for current WASM these values will be 32-bit with 32-bits of zeros, or are already 64-bit anyway?

So a future WASM 64 could still be handled by this packet?

[MaxDesiatov]

Wasm started out being 32-bits only and that's what we've be targeting in LLDB. Only recently a proposal for 64-bit Wasm was approved.

This proposal is already implemented in 2 out of 3 major browsers, so we need to be ready to deal with it. The underlying issue is that Wasm has separate code and data address spaces, but AFAIU LLDB doesn't support multiple address spaces, so both linear memory (data) and code need to fit in 64 bits, while both separately can take up to 64-bit address space each? In theory, one could have huge linear memory allocated utilizing whole 64-bit range (you need much less to allocate even a terabyte of memory), and exabytes of binary code at the same time, but I'm unsure how practical that is.

The convention I'm seeing Wasm runtimes use for LLDB is to put the whole binary Wasm module verbatim starting at 0x4000000000000000, and everything in lower address space is reserved for linear memory. Thus in practice PC values reported by these runtimes are always in 0x4000000000000000+ range. Unless LLDB is willing to support currently impractically huge both data and code amounts, 8 bytes should be enough for PC I guess?

[DavidSpickett]

So a future WASM 64 could still be handled by this packet?

To be clear, this is curiosity. It does not block improving the description of the current packet.

[MaxDesiatov]

Right, the point I'm trying to make is that this is not future Wasm, you can stumble upon 64-bit Wasm modules today. My opinion is that with the current setup in a single address space LLDB can handle all Wasm modules seen in practice, and if a hypothetical exabyte-size Wasm modules come up (if ever), we can deal with that later. Maybe with a future addition of qWasmCallStack64 or something like that.