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

On 1/16/25 10:37, Andrew Burgess wrote:
> Stephen Brennan via Gdb <[email protected]> writes:
> 
>> 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.
> 
> 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?