Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <vladimir@codesourcery.com>
To: Nick Roberts <nickrob@snap.net.nz>
Cc: gdb@sources.redhat.com
Subject: Re: [MI] frozen variable objects (bug)
Date: Wed, 27 Jun 2007 07:46:00 -0000	[thread overview]
Message-ID: <200706271146.29459.vladimir@codesourcery.com> (raw)
In-Reply-To: <18050.3617.437104.746324@kahikatea.snap.net.nz>

On Wednesday 27 June 2007 11:13, Nick Roberts wrote:
>  > > b) from -var-list-children, but the frozen flag is not set for children,
>  > > only
>  > >    for the variable object that was explicitly chosen 
>  > 
>  > I don't understand what do you mean by "explicitly chosen". Just like
>  > -var-create, in current FSF HEAD children varobjs always created non-frozen.
>  > You can freeze any children you like.
> 
> If you do:
> 
> -var-create - * m
> ^done,name="var1",numchild="4",value="[4]",type="int [4]"
> (gdb) 
> -var-list-children var1
> ^done,numchild="4",children=[child={name="var1.0",exp="0",numchild="0",type="int"},child={name="var1.1",exp="1",numchild="0",type="int"},child={name="var1.2",exp="2",numchild="0",type="int"},child={name="var1.3",exp="3",numchild="0",type="int"}]
> (gdb) 
> -var-set-frozen var1 1
> ^done
> (gdb)
> -var-list-children var1
> ^done,numchild="4",children=[child={name="var1.0",exp="0",numchild="0",type="int"},child={name="var1.1",exp="1",numchild="0",type="int"},child={name="var1.2",exp="2",numchild="0",type="int"},child={name="var1.3",exp="3",numchild="0",type="int"}]
> (gdb) 
> 
> as var->frozen = 1 for var1
> 
> but var->frozen = 0 for var1.0, var1.1, var1.2 and var1.3
> 
> I would expect the second -var-list-children to give:
> 
> ^done,numchild="4",children=[child={name="var1.0",exp="0",numchild="0",type="int",frozen="1"} etc
>   ^^^^^^^^^^

This is intentional. The frozen flag is set on specific variable, it's not recursively propagated to
children, in particular because that would serve no purpose -- if parent is frozen,
then children won't be implicitly updated anyway.

> 
>  > > I guess the front end should keep track of which objects are frozen but
>  > > it's an attribute that should/could be added to the MI command
>  > > -var-show-attributes.
>  > 
>  > We never established what's the intended use of -var-show-attributes and if
>  > that command should be present at all. 
> 
> Currently the front end can't query GDB to find out which variable objects
> are frozen.  Maybe that's not a problem but the manual says:
> 
>       -var-show-attributes NAME
> 
>    List attributes of the specified variable object NAME:
> 
>       status=ATTR [ ( ,ATTR )* ]
> 
> where ATTR is `{ { editable | noneditable } | TBD }'.
> 
> TBD - to be decided.  I guess that means things like "frozen".

Why would frontend want to query anything about variable object? Is there
a real case where frontend can't keep this information itself? If so,
should -var-show-attributes report expression, type, and so on?

> > Aside: I still don't understand the need for frozen objects.  In Emacs, if
> > I want to disable automatic update of a complex data type, I just click on
> > the parent to contract the display, which invokes "-var-delete -c" to
> > delete the
> > children.  If later I want to look at their values, clicking on the parent
> > regenerates the children.
> 
> > And how do you highlight values that were changed?
> 
> If I want to see if they've changed I don't delete them.  

And then on each step, all the memory for a varobj is read from target.
For large data structures on slow link, that will take considerable time.

> Maybe frozen objects 
> are helpful for some intermediate situation but I've never it experienced it.

It's unfortunate that you express those concerns now, and not when frozen
varobjs patch was floating on this list (which was for quite some time).

- Volodya



  reply	other threads:[~2007-06-27  7:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-26 22:47 Nick Roberts
2007-06-27  6:30 ` Vladimir Prus
2007-06-27  7:14   ` Nick Roberts
2007-06-27  7:46     ` Vladimir Prus [this message]
2007-06-27  8:19       ` Nick Roberts
2007-06-27 11:10       ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200706271146.29459.vladimir@codesourcery.com \
    --to=vladimir@codesourcery.com \
    --cc=gdb@sources.redhat.com \
    --cc=nickrob@snap.net.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox