From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19760 invoked by alias); 15 Apr 2007 10:19:29 -0000 Received: (qmail 19748 invoked by uid 22791); 15 Apr 2007 10:19:28 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 15 Apr 2007 11:19:25 +0100 Received: (qmail 11292 invoked from network); 15 Apr 2007 10:19:23 -0000 Received: from unknown (HELO ?172.16.64.38?) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Apr 2007 10:19:23 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: Ping: frozen variable objects Date: Sun, 15 Apr 2007 10:32:00 -0000 User-Agent: KMail/1.9.1 Cc: Daniel Jacobowitz , Eli Zaretskii , gdb-patches@sources.redhat.com References: <200703251351.43195.vladimir@codesourcery.com> <20070414161353.GA24574@caradoc.them.org> <17953.23395.177793.84085@farnswood.snap.net.nz> In-Reply-To: <17953.23395.177793.84085@farnswood.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704151419.15750.vladimir@codesourcery.com> 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-04/txt/msg00233.txt.bz2 On Sunday 15 April 2007 02:53, Nick Roberts wrote: > > > The range of values for fields with specified values, e.g., > > > -@code{in_scope} (@pxref{-var-update}) may be extended. > > > +@code{in_scope} (@pxref{-var-update-fields}) may be extended. > > > > Doesn't that read a little odd to you? I'd think '-var-update fields' > > at least. > > Also the name that is displayed shouldn't change, so pxref needs to be > called with two arguments: > > > @code{in_scope} (@pxref{-var-update fields, -var-update}) may be extended. > > and > > @anchor{-var-update fields} > The field in_scope may take three values: > > Here are some other observations about the documentation: > > frozenness (not a common word) has two ns. > > In the description for -var-set-frozen: > > parameter should be either `1' to make the variable frozen or `0' to > make it unfozen. If a variable object is frozen, then neither itself, > ^^^^^^^ > > In the description for -var-update: > > If `*' is used as the variable object names, all existing variable objects > are updated. > > Since frozen variables aren't updated implicitly, I would move some > of the description of them from -var-set-frozen to here. I think cross-reference will be fine. > @c The format of field's content e.g type prefix, may change so parse it > @c at your own risk. Yes, in general? > @@ -19536,7 +19536,10 @@ that corresponds to a composite type, su > a number of child variable objects, for example corresponding to each > element of a structure. A child variable object can itself have > children, recursively. Recursion ends when we reach > -leaf variable objects, which always have built-in types. > +leaf variable objects, which always have built-in types. Child variable > +objects are created only by explicit request, so if a frontend > +is not interested in the children of a particular variable object, no > +child will be created. > > 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 > @@ -19548,7 +19551,19 @@ A frontend does not need to read the val > the program stops. Instead, MI provides an update command that lists all > variable objects whose values has changed since the last update > operation. This considerably reduces the amount of data that must > -be transferred to the frontend. > +be transferred to the frontend. As noted above, children variable > +objects are created on demand, and only leaf variable objects have a > +real value. As result, gdb will read target memory only for leaf > +variables that frontend has created. > > Why not just: > > @c The format of field's content e.g type prefix, may change so parse it > @c at your own risk. Yes, in general? > @@ -19536,7 +19536,10 @@ that corresponds to a composite type, su > a number of child variable objects, for example corresponding to each > element of a structure. A child variable object can itself have > children, recursively. Recursion ends when we reach > -leaf variable objects, which always have built-in types. > +leaf variable objects, which always have built-in types. Child variable > +objects are created only by explicit request, so if a frontend > +is not interested in the children of a particular variable object, no > +child will be created. As result, gdb will read target memory only for > +leaf variables that frontend has created. Because I wanted to say that -var-update specifically does not read memory for entire structures. - Volodya