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