This is the mail archive of the
mailing list for the GDB project.
Re: [rfc/rfa] [3/4] SPU enhancements: gdbserver support
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: gdb-patches at sourceware dot org, eliz at gnu dot org
- Date: Mon, 4 Jun 2007 22:05:01 +0200 (CEST)
- Subject: Re: [rfc/rfa] [3/4] SPU enhancements: gdbserver support
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
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 == 'l')
> + if (rs->buf == '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 ...
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE