Mechanism for RSP's qXfer:write to indicate the end-of-file has been reached

Ciaran Woodward <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <PAXPR09MB558305EDC4A9131A0C134EB7B94D2@PAXPR09MB5583.eurprd09.prod.outlook.com>
Hi,

I'm currently implementing a custom gdb RSP server (stub).

While implementing the qXfer packet, I notice that while qXfer:read (server to client) has
a mechanism to detect EOF (the 'l' response), qXfer:write (client to server) does not.

https://sourceware.org/gdb/current/onlinedocs/gdb.html/General-Query-Packets.html#qXfer-write

It seems like currently it is possible from the RSP server side to make an 'educated guess'
of when a qXfer:write sequence is complete, by sending a response which indicates one-fewer
than the full length has been written, then treating a received follow-up packet of length
one as being the 'end'.

However, it isn't really explicit.

I think it might be neater to change the RSP slightly to more explicitly indicate a
completed qXfer:write operation, so that the server knows when the object has been
fully written.

I see a few options which I believe to be backwards-compatible, and I lean towards the first.
Just wondering if anyone else had any thoughts before I try and put a patch together.

1. GDB should send a qXfer packet with an empty data field to indicate end of file.
2. GDB should send a qXfer:written (new) packet to indicate end of file
3. Change nothing, leave RSP server implementations to implement a process like above if
   it cares about knowing the end of a file.

The qXfer:write packet is a pretty niche packet at the moment. I think this is only an issue in practice
if an RSP server has a particularly small max packet size, or for future/custom qXfer:write
objects which are larger.

Thanks,
Ciaran
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.