From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17730 invoked by alias); 4 Jun 2007 20:05:07 -0000 Received: (qmail 17722 invoked by uid 22791); 4 Jun 2007 20:05:06 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.29.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Jun 2007 20:05:04 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.8/8.13.8) with ESMTP id l54K52rt198840 for ; Mon, 4 Jun 2007 20:05:02 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l54K51lq3199128 for ; Mon, 4 Jun 2007 22:05:01 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l54K51WH029202 for ; Mon, 4 Jun 2007 22:05:01 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id l54K51nH029199; Mon, 4 Jun 2007 22:05:01 +0200 Message-Id: <200706042005.l54K51nH029199@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 4 Jun 2007 22:05:01 +0200 Subject: Re: [rfc/rfa] [3/4] SPU enhancements: gdbserver support To: drow@false.org (Daniel Jacobowitz) Date: Mon, 04 Jun 2007 20:05:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, eliz@gnu.org In-Reply-To: <20070604195349.GC23516@caradoc.them.org> from "Daniel Jacobowitz" at Jun 04, 2007 03:53:49 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00042.txt.bz2 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