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

[Luis Machado via Gdb <gdb@sourceware.org>]

On 1/16/25 16:40, Andrew Burgess wrote:
> 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.

All good points. I wasn't aware this particular feature existed to be honest.

I suppose my concerns are more towards having a packet that eventually starts
getting wider usage, and then people rely on it, but gdb doesn't know about it.

But I agree by then we should be able to make the call to internalize such packet
in GDB.

To be fair, given the nature of the RSP packets, it would make more sense to
have that parsed/handled via Python for simplicity/efficiency, as opposed to C/C++.

> 
> Thanks,
> Andrew
>