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

Tom Tromey <[email protected]> writes:
>>>>>> Luis Machado via Gdb <[email protected]> writes:
>
>>> 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.
>
> Agreed, qXfer is the way to go.

Thank you Tom & Luis for confirmation, qXfer seems appropriate. With
that approach the buffer size is not really a concern: we can simply use
the minimum of the requested read size, and the stub's buffer size. So
long as clients use multiple requests until the data is fully read.

While the "os" object also sounds like a good place to put this (e.g.
within a new annex), it seems like that contains XML-formatted data with
well-understood schema and semantics. The vmcoreinfo is free-form text
(generally of a "key=value" format), so it probably should be a separate
object.

So I think we would prefer to add an object type, e.g. named "vmcoreinfo".
(But please do speak up if this sounds like a mistake)

> If you're adding a new object type, a patch to the manual would be good.

I'll definitely include a patch for the manual in the plan for this.
Another patch I'd like to write is to allow GDB's server to expose this
object type when the target is an ELF core dump with a VMCOREINFO note.
We're hoping for this to useful for all debuggers, not just drgn.

Thanks again!
Stephen