Re: GDB Remote Protocol Extension - Linux VMCOREINFO - Request for Feedback

["Thomas Weißschuh via Gdb" <gdb@sourceware.org>]

On 2025-01-27 10:42:59-0800, Stephen Brennan wrote:
> Omar Sandoval <osandov@osandov.com> writes:
> > On Sun, Jan 26, 2025 at 07:07:47PM +0100, Thomas Weißschuh wrote:
> >> On 2025-01-13 16:22:00-0800, Stephen Brennan wrote:

<snip>

> >> Do you need to transfer the full vmcoreinfo data?
> >> Wouldn't it be sufficient to only include the address/size of the
> >> vmcoreinfo note in memory and the debugger can read the data from there
> >> with regular memory access commands?
> >> That information is enough for QEMUs vmcoreinfo device.
> >> It would simplify the design and implementation(s) significantly.
> 
> I do agree that this would simplify the protocol design, and it's a good
> idea I hadn't considered. Thank you!
> 
> > Oh, that's a good idea. I guess the downside is an extra command round
> > trip.
> >
> > QEMU and KGDB also only implement the `m` command for reading
> > hex-encoded memory. We'd probably want to implement the `x` command for
> > both since it doesn't (usually) double the transfer size.
> >
> > One more caveat is that KGDB doesn't check the length passed to the `m`
> > command and will happily clobber memory... QEMU's gdbstub does seem to
> > check, and also advertises its packet size, so we probably want that in
> > KGDB, too.
> >
> > Stephen, what do you think?
> 
> One of our core constraints is that the vmcoreinfo is quite a bit of
> text data, around 3k bytes right now. Doubling that to 6k would be a
> real problem, so it would be really helpful to keep this to using the
> 'x' encoding. However, I think there's a couple good reasons that
> neither QEMU nor KGDB support the 'x' packet:

Could you elaborate why it "would be a real problem"?
If it is a problem with static buffer sizes, wouldn't this be avoided by
configuring a max packet size? The debugger would have to request the
data in chunks.

This is also what the drgn pull request currently does for all memory reads.
Without knowing much about drgn, I would have expected the regular
memory accesses to be much more data then the 3KB vmcore notes.

> 1. You cannot know the required buffer size easily, so you cannot know
> whether you will be able to satisfy an 'x' request in your static buffer
> size. This is most relevant to kgdb. The 'x' packet documentation says:
> 
>   The reply may contain fewer addressable memory units than requested if
>   the server was reading from a trace frame memory and was able to read
>   only part of the region of memory. 
> 
> I'm not certain what trace frame memory is, but the vmcoreinfo is not
> that. I'm not confident whether this means the protocol allows fewer
> bytes to be returned for other cases? Certainly, the 'qXfer' packets
> explicitly allow for fewer bytes to be returned, as the documentation
> states:
> 
>   It is possible for data to have fewer bytes than the length in the
>   request. 

If I understand correctly "trace frame" refers to same sort of cache.
It's not a property of the target memory but how it is managed by gdb.

For m reads, gdb itself explictly seems to allow short reads, also
referring (not exclusively) to trace frames.

Server:

/* Read trace frame or inferior memory.  Returns the number of bytes
   actually read, zero when no further transfer is possible, and -1 on
   error.  Return of a positive value smaller than LEN does not
   indicate there's no more to be read, only the end of the transfer.
   E.g., when GDB reads memory from a traceframe, a first request may
   be served from a memory block that does not cover the whole request
   length.  A following request gets the rest served from either
   another block (of the same traceframe) or from the read-only
   regions.  */

static int
gdb_read_memory (CORE_ADDR memaddr, unsigned char *myaddr, int len)
...

Client:

target_xfer_status
remote_target::remote_read_bytes_1 (CORE_ADDR memaddr, gdb_byte *myaddr,
				    ULONGEST len_units,
				    int unit_size, ULONGEST *xfered_len_units)
{
  ...

  decoded_bytes = hex2bin (p, myaddr, todo_units * unit_size);
  /* Return what we have.  Let higher layers handle partial reads.  */
  *xfered_len_units = (ULONGEST) (decoded_bytes / unit_size);
  return (*xfered_len_units != 0) ? TARGET_XFER_OK : TARGET_XFER_EOF;
}

<snip>


Thomas