From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6066 invoked by alias); 26 May 2016 20:33:59 -0000 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 Received: (qmail 6055 invoked by uid 89); 26 May 2016 20:33:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:sk:mailhub, H*RU:sk:mailhub, H*UA:1.5, responses X-HELO: mailuogwdur.emc.com Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 26 May 2016 20:33:45 +0000 Received: from maildlpprd51.lss.emc.com (maildlpprd51.lss.emc.com [10.106.48.155]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u4QKXeTN027144 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 May 2016 16:33:40 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u4QKXeTN027144 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com u4QKXeTN027144 Received: from mailsyshubprd07.lss.emc.com (mailhub.lss.emc.com [10.253.24.63]) by maildlpprd51.lss.emc.com (RSA Interceptor); Thu, 26 May 2016 16:33:11 -0400 Received: from usendtaylorx2l (d5170089.lss.emc.com [10.243.146.89]) by mailsyshubprd07.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u4QKXRrs004815; Thu, 26 May 2016 16:33:27 -0400 Received: by usendtaylorx2l (Postfix, from userid 26043) id 96586261118; Thu, 26 May 2016 16:33:27 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l (Postfix) with ESMTP id 6B9CC260B27; Thu, 26 May 2016 16:33:27 -0400 (EDT) From: David Taylor To: Eli Zaretskii cc: gdb-patches@sourceware.org, dtaylor@emc.com Subject: Re: [PATCH] Document short responses to qXfer:object:read. Date: Thu, 26 May 2016 20:33:00 -0000 Message-ID: <25526.1464294807@usendtaylorx2l> X-RSA-Classifications: public X-Sentrion-Hostname: mailuogwprd53.lss.emc.com X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00476.txt.bz2 > From: Eli Zaretskii > Date: Thu, 26 May 2016 22:31:40 +0300 > > > From: David Taylor > > cc: dtaylor@emc.com > > Date: Thu, 26 May 2016 14:10:37 -0400 > > > > +2016-05-26 David Taylor > > + > > + * gdb.texinfo (General Query Packets): Document treatment of short > > + qXfer responses and EOF indication. > > + > > 2016-05-23 Tom Tromey > > > > * python.texi (Basic Python): Document gdb.breakpoints return. > > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > > index 8f1ad4e..c674c7a 100644 > > --- a/gdb/doc/gdb.texinfo > > +++ b/gdb/doc/gdb.texinfo > > @@ -37251,6 +37251,11 @@ starting at @var{offset} bytes into the data. The content and > > encoding of @var{annex} is specific to @var{object}; it can supply > > additional details about what data to access. > > > > +The target is permitted to return a short response. The response is > > +considered to cover the range @var{offset} (inclusive) to @var{offset} > > ++ @var{response length} (exclusive). End of file is indicated by a > > +zero length response. > > + > > Here are the specific requests of this form defined so far. All > > @samp{qXfer:@var{object}:read:@dots{}} requests use the same reply > > formats, listed below. > > Thanks. However, I have difficulty understanding what this text is > trying to convey. Problematic words are "permitted" and "short" -- > they don't seem to be related to anything around this text, and are > not explained by the text itself. I also don't see why EOF is > important here, or even related. > > Could you perhaps explain in your own words what is this about, and > what the text lacks without this paragraph? I might then propose a > more clear wording. > > Thanks. The qXfer:object:read packet contains an offset and a length. It says for , starting at offset , send me characters. When 'reading' object , GDB starts at offset 0 and sends qXfer::read packets with progressively higher offsets until it gets everything. If it was a file, then a read of less than the requested amount (aka a short read) would be interpreted as having reached the end of the file. These objects aren't really files. And returning less than requested does not mean that the end of the object has been reached. GDB's next 'read' from 'object' will be at offset + NOT at + The fact that sending back less than requested is okay (i.e., does not say to GDB -- hey, that's it, there is no more) and that the next request starts where the last response ended (i.e., offset + returned amount) rather than where the last request ended (i.e., offset + requested amount) makes life easier on the remote stub implementer. Hope that clarifies somewhat. Now, can we come up with better wording? David