This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [MI] frozen variable objects (bug)


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]