From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4169 invoked by alias); 29 Mar 2006 21:26:39 -0000 Received: (qmail 4161 invoked by uid 22791); 29 Mar 2006 21:26:38 -0000 X-Spam-Check-By: sourceware.org Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.198) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 29 Mar 2006 21:26:37 +0000 Received: by xproxy.gmail.com with SMTP id s16so217945wxc for ; Wed, 29 Mar 2006 13:26:36 -0800 (PST) Received: by 10.70.104.12 with SMTP id b12mr1544523wxc; Wed, 29 Mar 2006 13:26:36 -0800 (PST) Received: by 10.70.126.16 with HTTP; Wed, 29 Mar 2006 13:26:36 -0800 (PST) Message-ID: <8f2776cb0603291326w1242641ct66598d738f5a1454@mail.gmail.com> Date: Wed, 29 Mar 2006 22:27:00 -0000 From: "Jim Blandy" To: "Eli Zaretskii" Subject: Re: Self-describing targets - a more concrete proposal Cc: gdb@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060329161624.GA32241@nevyn.them.org> 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-03/txt/msg00201.txt.bz2 On 3/29/06, Eli Zaretskii wrote: > > Date: Wed, 29 Mar 2006 11:16:25 -0500 > > From: Daniel Jacobowitz > > > > I would appreciate comments on the sample and documentation > > Comments on the documentation are below. Note that I needed to guess > what was in the Texinfo source, since you posted the Info output, so I > could have guessed wrong, and my comments might thus be off the target. Thanks very much. We wanted to get comments on the actual design itself, so we posted legible text instead of a texinfo patch. When it comes down to posting the final patch, we'll certainly include the patch to gdb.texinfo in the usual way. > > GDB retrieves a target's self-description via the remote protocol using > > a `qPart' request (*note the `qPart' request: qPart request.) of the fo= rm: > > This cross-reference looks awkward. I'm guessing that Jim used a > 2-argument form of a @pxref here. But the second arg is redundant > here because it is a substring of the 1st. Am I missing some valid > reason for using the second argument? It does look awkward. I wanted to use @code for qPart. But I'm not sure it's worth it; I've simplified it and it seems okay. > > qPart:features:read:ANNEX:OFFSET,LENGTH > > where ANNEX is the string `target.xml'. The OFFSET and LENGTH > > The last line should have a @noindent before it. Done. > > parameters are the offset into the description and the number of bytes > > to transfer, as for other `qPart' requests. > > > > The `target.xml' annex contains an XML document describing the > > target's features; its form is described in *Note Self-Description > > Format::. > > There's something I don't understand here: is "target.xml" a literal > fixed string that will _always_ appear in the above packet? If it is, > why do we need to mention its name? We talk about GDB retrieving other annexes (annices?) later; that request is used for all of them. I'll try to rephrase this. > > To reduce protocol overhead, a target may supply a special annex > > named `CHECKSUMS' that provides 160-bit SHA1 checksum values for the > > annexes it has available. The `CHECKSUMS' annex contains a series of > > newline-terminated lines, each of which contains a 40-digit hexidecimal > > checksum, two spaces, and the name of an annex with the given checksum. > > Here is an example `CHECKSUM' annex: > > 68c94ffc34f8ad2d7bfae3f5a6b996409211c1b1 target.xml > > 0e8e850b0580fbaaa0872326cb1b8ad6adda9b0d mmu.xml > > 00f22e5f971ccec05c2acce98caf8cff4343c8cf fpu.xml > > Shouldn't we document how to generate a checksum for a file? SHA-1 is the name of the specific hash function that must be used.=20 I'll clear this up. > Other than that, looks fine to me. As always, thanks for the review!