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

[Andrew Burgess via Gdb <gdb@sourceware.org>]

Luis Machado <luis.machado@arm.com> writes:

> On 1/16/25 10:37, Andrew Burgess wrote:
>> Stephen Brennan via Gdb <gdb@sourceware.org> writes:
>> 
>>> Tom Tromey <tom@tromey.com> writes:
>>>>>>>>> Luis Machado via Gdb <gdb@sourceware.org> 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.
>> 
>> Hi Stephen,
>> 
>> I took a look at the wiki page and it seems like initially at least,
>> your plan is to make the information from vmcoreinfo available via a new
>> 'info' command.
>> 
>> It is possible to send remote packets through GDB's Python API[1].  And
>> of course, the Python API allows for new commands to be created[2].
>> There is a test in GDB's test suite that makes use of the packet sending
>> API, and it happens to send a qXfer packet[3].
>> 
>> I say all this not to put you off contributing a patch to core GDB, but
>> if what you want is a new user command which will send a packet to a
>> remote target and process the results, then it should be possible to
>> implement this as a Python extension.
>
> A bit off-topic, but wouldn't that have the potential to proliferate
> remote packets gdb/debugging stubs have no control over or no documentation
> to point at/refer to? Possibly contributing to greater confusion as to what
> should be minimally supported in terms of remote packets?

I don't see a problem, but that doesn't mean using an extension is the
right choice in all cases.

Using an extension, in my mind, ties the functionality to the project.
So if we expect many remote targets to support the new packet then it
begins to make more sense to move the functionality into the GDB tree
(maybe as C++ code, or maybe as Python code).  But if, really, the new
feature only applies for one project, then it makes more sense (for me)
to add GDB support via an project specific extension.  Documentation
would naturally live within the project itself.

On the topic of control, I'm not entirely sure what problems you see.
Using a project specific extension gives (IMHO) the project more control
over the packet as they are free to change the packet over time.
Currently GDB is pretty conservative with changing packets, so if a
single project pushed their own custom packet to GDB core, and then
wanted to change the packet, there's a risk we (GDB team) might refuse
the change "just in case" someone else has since started to use the
packet.  That might be seen as the project having less control.

Looking at GDB's control over packets, I'm not sure what control GDB
needs.  For sure, there's a risk that if extensions start creating their
own packets then there is a risk that GDB might later add a conflicting
packet, which could be a problem, and one reason we might want to move
from an extension to a core packet.  I doubt, right now, there are many
"custom packets" in the wild, but maybe we should consider defining
namespaces for custom packets, to avoid future conflicts?

The minimally supported problem is usually about the minimal set of
packets that a remote target needs to support, rather than the set GDB
supports.  In most cases, communication is initiated by GDB, so if GDB
isn't aware of this packet (extension not loaded), GDB will just never
ask for it.

I'm certainly not making the argument that using an extension is the
right choice in every case.  Not every packet type is going to be right
for implementing as an extension.  Additionally, it might be that a
project starts with an extension while prototyping a new packet, and
then ports it to C++ and contributes it to GDB later once the design is
solid.

I've had success using packets via Python before, and not everyone is
aware this feature is available, so I thought I'd mention it.

Thanks,
Andrew