Re: qXfer:threads:read packets

[Pedro Alves <palves at redhat dot com>]

On 05/09/2016 08:02 PM, taylor, david wrote:
> I'm looking to implement qXfer:threads:read for our remote target.
> To that end, I have some questions and observations.
> 
> In appendix E, section 17 (Thread List Format), the manual gives
> an example of the response to the qXfer:threads:read packet.
> In part it reads:
> 
>     <thread id="id" core="0" name="name">
> 
> But, file gdb/features/threads.dtd does not mention 'name'.
> Is this a bug?  A misunderstanding on my part?  Something else?

A bug.

> 
> The documentation does not say what happens when a target gives
> a short response to a qXfer:threads:read request.
> 
> Reading the code, the current GDB requires a zero length reply for EOF.

It does not.  See remote.c:remote_read_qxfer and:

  /* Check whether we've cached an end-of-object packet that matches
     this request.  */
  if (rs->finished_object)
...
  /* 'l' is an EOF marker, possibly including a final block of data,
     or possibly empty.  If we have the final block of a non-empty
     object, record this fact to bypass a subsequent partial read.  */
  if (rs->buf[0] == 'l' && offset + i > 0)
    {


> Is it okay to document this?  

No.  What matters is "m" vs "l".

> Also, the 'offset' for the next packet is the
> previous offset plus the length of the previous reply (not the requested
> length in the previous packet).
> 

I don't think we should document that.  All the stub needs to care about
is respect the requested "offset", no matter what the previous request
happened to be.  It may be that for xml-based objects, this won't ever change
in practice, but that's certainly not something we'd want to require
for binary objects like siginfo, etc.

Thanks,
Pedro Alves