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

Hi Stephen,

I think you want either [email protected] or [email protected]. This
is the binutils mailing list.

On 1/14/25 00:22, Stephen Brennan wrote:
> 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?

It is hardcoded by gdb, but the remote can also specify that, but...

> 2. Would this functionality be better implemented in a single "q
>    linux.vmcoreinfo" packet, or as a "qXfer" packet?

... we have packets like qXfer that can handle multi-part transfers. So the
packet size is not a critical concern anymore, and it is best to use this
newer mechanism, if the usage fits the packet structure.

> 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)?

Yes, gdb uses qXfer to read the remote's auxv file, for instance.

  [remote] Sending packet: $qXfer:auxv:read::0,1000#6b
  [remote] Packet received: l!\000\000\000\000\000\000\000\000\000\0003\000\000\000\000\000\000\000p\022\000\000\000\000\000\000\020\000\000...

> 
> 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/[email protected]/T/#mad965a732c1c5e9e2656e4be79ffcdc36d89b7d1
> [6]: https://sourceware.org/gdb/current/onlinedocs/gdb.html/General-Query-Packets.html#qXfer-read