Re: [rfc/rfa] [3/4] SPU enhancements: gdbserver support

["Ulrich Weigand" <uweigand@de.ibm.com>]

Daniel Jacobowitz wrote:

> > - It adds a "length" argument to qXfer::write type packets.  This is
> >   to make parsing of the packet easier, and to bring it in line with
> >   the 'X' packet format.  (It also provides a bit of extra redundancy
> >   to detect transmission problems.)
> 
> It adds another case that stubs need to check for (length != length of
> supplied data), and it's redundant.  I have some code already written
> to generate and parse binary packets without a specified length, if
> you'd like me to post it.  It's for the project I'm going to submit
> once I finish with shared library lists - file transfer through
> gdbserver.

Fine with me.  I'd appreciate if you could post that code ...

> > - The remote_read_qxfer attempts to cache received end-of-object
> >   packets.  However, this is a problem for some spufs objects as
> >   they can start out with no content (length zero), and acquire
> >   actual content later on.  If remote_read_qxfer has already cache
> >   an end-of-object at lenght zero, future re-reads of the object
> >   will always return zero even if the object by now has actual
> >   content.  To fix this we've added a CACHEABLE flag to the
> >   function and use it to disable the cache for spufs objects.
> 
> How about this simpler fix?
> 
> -  if (rs->buf[0] == 'l')
> +  if (rs->buf[0] == 'l' && offset + i > 0)
> 
> It's only supposed to trigger for the next part of the same read
> operation.  If we got no bytes, then the operation is already over.

That should fix our problem as well.  I just wasn't sure if the
existing behaviour was deliberate for the other packet types ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com