Author: Felipe de Azevedo Piovezan Date: 2025-10-15T08:02:39-07:00 New Revision: e91786a84967e006b21f2eb0eb59a56b2f925eac
URL: https://github.com/llvm/llvm-project/commit/e91786a84967e006b21f2eb0eb59a56b2f925eac DIFF: https://github.com/llvm/llvm-project/commit/e91786a84967e006b21f2eb0eb59a56b2f925eac.diff LOG: [gdbremote] Document MultiMemRead packet in protocol extensions (#162675) This adds a specification for the new packet discussed in the RFC [1]. [1]: https://discourse.llvm.org/t/rfc-a-new-vectorized-memory-read-packet/88441/12 Added: Modified: lldb/docs/resources/lldbgdbremote.md Removed: ################################################################################ diff --git a/lldb/docs/resources/lldbgdbremote.md b/lldb/docs/resources/lldbgdbremote.md index 93fb0c9b5502f..f0c5e6b04d54c 100644 --- a/lldb/docs/resources/lldbgdbremote.md +++ b/lldb/docs/resources/lldbgdbremote.md @@ -738,6 +738,57 @@ This is a performance optimization, which speeds up debugging by avoiding multiple round-trips for retrieving thread information. The information from this packet can be retrieved using a combination of `qThreadStopInfo` and `m` packets. +### MultiMemRead + +Read memory from multiple memory ranges. + +This packet has one argument: + +* `ranges`: a list of pairs of numbers, formatted in base-16. Each pair is +separated by a `,`, as is each number in each 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. The list must end with a `;`. + +The reply packet starts with a comma-separated list of numbers formatted in +base-16, denoting how many bytes were read from each range, in the same order +as the request packet. The list is followed by a `;`, followed by a sequence of +bytes containing binary encoded data for all memory that was read. The length +of the binary encodeed data, after being decoded as required by the GDB remote +protocol, must be equal to the sum of the numbers provided at the start of the +reply. The order of the binary data is the same as the order of the ranges in +the request packet. + +If some part of a range is not readable, the stub may perform a partial read of +a prefix of the range. In other words, partial reads will only ever be from the +start of the range, never the middle or end. Support for partial reads depends +on the debug stub. + +If, by applying the rules above, the stub has read zero bytes from a range, it +must return a length of zero for that range in the reply packet; no bytes for +this memory range are included in the sequence of bytes that follows. + +A stub that supports this packet must include `MultiMemRead+` in the reply to +`qSupported`. + +``` +send packet: $MultiMemRead:ranges:100a00,4,200200,a0,400000,4; +read packet: $4,0,2;<binary encoding of abcd1000><binary encoding of eeff> +``` + +In the example above, the first read produced `abcd1000`, the read of `a0` +bytes from address `200200` failed to read any bytes, and the third read +produced two bytes – `eeff` – out of the four requested. + +``` +send packet: $MultiMemRead:ranges:100a00,0; +read packet: $0; +``` + +In the example above, a read of zero bytes was requested. + +**Priority to Implement:** Only required for performance, the debugger will +fall back to doing separate read requests if this packet is unavailable. + ## QEnvironment:NAME=VALUE Setup the environment up for a new child process that will soon be _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
