GDB Remote Protocol Extension - Linux VMCOREINFO - Request for Feedback

[Stephen Brennan <stephen.s.brennan@oracle.com>]

Hello all,

I contribute to the drgn debugger [1], and work on debugging the Linux
kernel a fair bit. Drgn is particularly well-suited to the Linux kernel
and contains a lot of support for it. It currently supports attaching to
live targets via Linux's /proc/kcore, and core dumps. We are looking
into supporting remote targets via GDB's remote protocol.

One piece of information that is very useful when debugging the Linux
kernel is the VMCOREINFO note[2]. This is a free-form piece of text
data, typically around 3k bytes, which contains information that
debuggers would find useful in interpreting a Linux kernel memory image.
In particular, it contains the KASLR offset, the build ID of the kernel,
and the OS release. With this information, a debugger could attach to
a live GDB stub (e.g. kgdb, or QEMU) without needing to specify
debuginfo file names or memory KASLR memory offsets.

To that end, we hope to extend the GDB remote protocol with a facility
that would allow the debugger to request this information. We've written
up an idea for this proposal at [3]. The summary is:

  'q linux.vmcoreinfo'
     Retrieves the Linux vmcoreinfo data.
     Reply:
     'Q [DATA]' data is encoded as described in the Binary Data doc [4]
     'E.<text>' with an informative message if the data is not available

However, with the candidate kgdb implementation taking shape [5], we're
becoming concerned regarding this design. It seems that there is an
implicit maximum packet size which is not described in the protocol
documentation. Many stubs have small(ish) shared output buffers. It
seems to me that data which would be 3k bytes before escaping is too
large. We've noticed that there is a 'qXfer' query packet which allows
specifying an offset and a number of bytes. Maybe it would be better for
us to add a new 'special data area' for the 'qXfer' message, and reuse
that command?

To sum up, my specific questions are:

1. What is the maximum protocol packet size, if any?
2. Would this functionality be better implemented in a single "q
   linux.vmcoreinfo" packet, or as a "qXfer" packet?
3. Is it safe to assume that data transmitted in the qXfer packets is
   encoded via the escaped binary data format described at [4] (rather
   than the hexadecimal encoding)?

Any other feedback is welcome too.
Thanks,
Stephen

[1]: https://github.com/osandov/drgn
[2]: https://docs.kernel.org/admin-guide/kdump/vmcoreinfo.html
[3]: https://github.com/osandov/drgn/wiki/GDB-Remote-Protocol-proposal:-linux.vmcoreinfo-query-packet
[4]: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Overview.html#Binary-Data
[5]: https://lore.kernel.org/linux-debuggers/20241210133448.3684593-1-tjarlama@gmail.com/T/#mad965a732c1c5e9e2656e4be79ffcdc36d89b7d1
[6]: https://sourceware.org/gdb/current/onlinedocs/gdb.html/General-Query-Packets.html#qXfer-read