[Lldb-commits] [lldb] [gdbremote] Document MultiMemRead packet in protocol extensions (PR #162675)

Felipe de Azevedo Piovezan via lldb-commits lldb-commits at lists.llvm.org
Sat Oct 11 06:55:14 PDT 2025


================
@@ -2530,3 +2530,41 @@ read packet: $e0030100#b9
 
 **Priority to Implement:** Only required for Wasm support. Necessary to show
 variables.
+
+### MultiMemRead
+
+Read memory from multiple memory addresses.
+
+There are two arguments to the request:
+
+* `ranges`: a list of base-16 pairs of numbers. Each pair is separated by a
+`,`, as is each number in the pair. The first number of the pair denotes the
+base address of the memory read, the second denotes the number of bytes to be
+read.
+* `options`: an optional string of options. If present, it may be empty. If
+present, it is the last argument of the request.
+
+Both arguments must end with a `;`.
+
+The reply packet starts with a comma-separated list of base-16 numbers,
+denoting how many bytes were read from each address, followed by a `;`,
+followed by a sequence of bytes containing the memory data. The length of this
+sequence must be equal to the sum of the numbers provided at the start of the
+reply.
+
+If the stub is unable to read from any individual address, it should return a
+length of "zero" for that address in the reply packet.
+
+A stub that supports this packet should return `MultiMemRead+` in the reply to
----------------
felipepiovezan wrote:

I think it's fine to require the answer to be included in `qSupported`; the code to add such answer should be a one-liner in any stub's code that implements `qSupported`. Parsing the answer could be more more work if the debugger is not already parsing that packet, but sending `qSupported` is still optional.

How each debugger chooses to detected the availability of the packet is up to them. As we've established, we can unambiguously distinguish the case of "I don't know this packet type!" from "we didn't read any bytes", since `MultiMemRead`'s reply will not be an empty string in that case (it will be `0;`). Both approaches (`qSupported` and `MultiMemRead:0,0;`) work.

`ProcessGDBRemote` is already sending and parsing `qSupported`, so it's less code for that particular implementation.

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


More information about the lldb-commits mailing list