Re: [PATCH] Document short responses to qXfer:object:read.

[Eli Zaretskii <eliz at gnu dot org>]

> From: David Taylor <dtaylor@emc.com>
> cc: gdb-patches@sourceware.org, dtaylor@emc.com
> Date: Thu, 26 May 2016 16:33:27 -0400
> 
> The qXfer:object:read packet contains an offset and a length.  It says
> for <object>, starting at offset <offset>, send me <length> characters.
> 
> When 'reading' object <object>, GDB starts at offset 0 and sends
> qXfer:<object>:read packets with progressively higher offsets until it
> gets everything.
> 
> If it was a file, then a read of less than the requested amount (aka a
> short read) would be interpreted as having reached the end of the file.
> 
> These objects aren't really files.  And returning less than requested
> does not mean that the end of the object has been reached.
> 
> GDB's next 'read' from 'object' will be at offset
> 
>     <offset> + <returned amount>
> 
> NOT at
> 
>     <offset> + <requested amount>
> 
> The fact that sending back less than requested is okay (i.e., does not
> say to GDB -- hey, that's it, there is no more) and that the next
> request starts where the last response ended (i.e., offset + returned
> amount) rather than where the last request ended (i.e., offset +
> requested amount) makes life easier on the remote stub implementer.
> 
> Hope that clarifies somewhat.

It very much does, thanks.  I have 3 follow-up questions:

 . It's not clear to me what is the "returned amount" here, as the
   listed responses for this packet don't seem to provide the amount
   of data in the response.  Do you mean the length of the data in the
   "m DATA" or "l DATA" responses, counted in bytes?

 . What is a zero-length response?  Is that "l" without data?

 . If my interpretation of the above 2 issues is correct, then why do we
   need this new text you suggest?  The 'm' and 'l' responses already
   say that the data can be shorter than the request, which seems to
   be what the new text says.

Finally, it looks to me that we should move the description of the
responses to precede the details of the 'read' requests, since the
list of those requests is very long, and thus the promised description
of the responses "below" is very far away, which IMO gets in the way
of reading and comprehending the issue.

> Now, can we come up with better wording?

After we've figured out the above left-overs, sure.

Thanks.