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

[Ciaran Woodward]

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