From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17955 invoked by alias); 20 Dec 2006 20:52:56 -0000 Received: (qmail 17946 invoked by uid 22791); 20 Dec 2006 20:52:55 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 20 Dec 2006 20:52:47 +0000 Received: from kahikatea.snap.net.nz (p202-124-125-15.snap.net.nz [202.124.125.15]) by viper.snap.net.nz (Postfix) with ESMTP id 5BE923D8A49; Thu, 21 Dec 2006 09:54:14 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 500) id 457D4BE374; Thu, 21 Dec 2006 09:48:07 +1300 (NZDT) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17801.41350.896824.320649@kahikatea.snap.net.nz> Date: Wed, 20 Dec 2006 20:52:00 -0000 To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: [doc] improve MI varobj introduction In-Reply-To: <200612201446.31705.vladimir@codesourcery.com> References: <200612191103.55137.vladimir@codesourcery.com> <17800.26295.304176.572103@kahikatea.snap.net.nz> <200612201446.31705.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.0.92.1 X-IsSubscribed: yes 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: 2006-12/txt/msg00270.txt.bz2 Vladimir Prus writes: > On Wednesday 20 December 2006 01:24, Nick Roberts wrote: > > > > I think it's a good idea to add this. > > > > > +For a leaf variable object it is possible to obtain its value as a > > > +string, or set the value from a string. String value can be also > > ^^^^^^ > > -var-assign var1 8 <- not a string > > ^done,value="8" > > Actually, it is. The entire MI interface is based on strings. You cannot do: > > int value; > mi_assign("V", value); I don't follow. AFAICS there is no function mi_assign and the manual is about the interface not GDB internals. > You mean the first two paragraphs? Let me go though them: > > - The basic idea behind variable objects is the creation > > This passage is just awkward, if not grammatically wrong. > > of a named object > -to represent a variable, an expression, a memory location or even a CPU > -register. For each object created, a set of operations is available for > -examining or changing its properties. > > "Examining or changing its properties" is very vague. This is the first > paragraph of the introduction to MI varobjs, it should explicitly say what > user might want to use them for -- and abstract "property" is not explicit > enough. I had no problem when I first read it but in any case it's Eli's call. > -Furthermore, complex data types, such as C structures, are represented > -in a tree format. For instance, the @code{struct} type variable is the > -root and the children will represent the struct members. If a child > -is itself of a complex type, it will also have children of its own. > > This is not so bad, but it fails to describe important properties of this > tree -- namely that only leafs carry any data. That's why I suggested _adding_ your paragraph. > -Appropriate language differences are handled for C, C@t{++} and Java. > > This sentence is content-free. It's pretty obvious that a debugger cannot be > language-agnostic, and it's not clear that "Appropriate" differences are > and why would I care. It tells me variable objects might not work for other languages. > > or that elaborating on the PRINT-VALUES option is a good idea. > > You mean the suggestion to use --all-values. I think it's important > information, and given that we have just one MI doc document, it's natural > to include this information. MI docs presently have too little content, not > too much. I don't think the manual should recommend ways to use MI commands. I guess it could say that the @samp{--all-values} option reduces the number of MI commands needed +on each program stop. but that should be obvious anyway and we're starting to guess how someone is using MI. > > Also expanding the introduction allows the removal of the summary of > > commands which just duplicates what comes after. > > I'm not sure -- which summaries can be removed now? The list just after: The following is the complete set of GDB/MI operations... -- Nick http://www.inet.net.nz/~nickrob