From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9306 invoked by alias); 18 Jan 2006 23:18:43 -0000 Received: (qmail 9289 invoked by uid 22791); 18 Jan 2006 23:18:42 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 18 Jan 2006 23:18:39 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1EzMZZ-0004wx-Gy for gdb@sourceware.org; Wed, 18 Jan 2006 18:18:37 -0500 Date: Wed, 18 Jan 2006 23:19:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: to_xfer_partial, qPart, and EOF Message-ID: <20060118231837.GA17726@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00177.txt.bz2 I started adding a new qPart packet type today and discovered that the current status quo is fairly confused. I'll start with the qPart packet. Some highlights can be found here, in Roland's posting of the protocol documentation: http://sources.redhat.com/ml/gdb/2004-02/msg00033.html The original posting used a reply of =DATA to mean "here's something, and EOF", and +DATA to mean "here's something, but there might be more". It did not explicitly mention short responses. Andrew revised this to something very like the final form; that final form is: Reply: `OK' The OFFSET in the request is at the end of the data. There is no more data to be read. XX... Hex encoded data bytes read. This may be fewer bytes than the LENGTH in the request. `E00' The request was malformed, or ANNEX was invalid. `E'NN The offset was invalid, or there was an error encountered reading the data. NN is a hex-encoded `errno' value. `""' (empty) An empty reply indicates the OBJECT or ANNEX string was not recognized by the stub. So, short responses are allowed, and they do not imply EOF. A problem with this is that the short reply indicating EOF has gotten lost. Roland wrote: > This looks fine to me, basically. But I do think it is worth starting out > with the one more wrinkle of EOF reporting along with data return. With > this simpler protocol, there are necessarily two request/reply transactions > for every time you want to read "all the data", even if there is as little > as one byte of it to read. That seems unnecessary and undesireable. > (Perhaps I've spent too long doing serial debugging when serial ports were > slower than they usually are these days. But all the remote protocol > traffic adds up to slow sessions hacking kernels.) I'm currently very well aware of the round trip latency in the remote protocol; it makes a huge difference over TCP, where larger packets are basically free up to a certain size, but round trips are very slow. At the time he wanted to pursue this immediately; Andrew wanted to go without it for the moment, and it was never revisited. So that's action item one; I think it's time to add this. So far so good. I also looked at the existing code in GDB. The remote.c support, as originally committed and still today reads the whole object in remote_xfer_partial (it will loop and send multiple packets if necessary). It was approved, of course, but I get the impression Andrew didn't much look at it - he would have jumped on that normally. There's several matching bugs in auxv.c: it asserts that there were no short reads, and it does the second and later reads still with offset 0 but puts them into consecutive locations in the buffer. Good thing no one's auxv vector ever exceeds that first read in practice. My current proposal is to make these changes: - Allow the qPart remote packet to signal EOF after a read. I think the best options are an equals sign at the beginning of the packet (as Roland suggested originally), or an equals sign at the end of the packet (which might be easier on stubs). - Modify the to_xfer_partial interface to signal EOF independently from buffer length. I don't see a way to do this other than by adding an argument to target_read_memory and all to_xfer_partial implementations. Any comments on either of these plans? Otherwise I will probably implement them in the next couple of days. I'm doing a lot of work in this area at present. -- Daniel Jacobowitz CodeSourcery