[MI] frozen variable objects (bug)

[MI] frozen variable objects (bug)

[Nick Roberts]

In principle, if a variable object is frozen, print_varobj prints it's
state out with:

  if (varobj_get_frozen (var))
    ui_out_field_int (uiout, "frozen", 1);

In practice this never happens because print_varobj is called

a) from -var-create, in which case the object can only be frozen _after_ it
  is created.

b) from -var-list-children, but the frozen flag is not set for children, only
   for the variable object that was explicitly chosen (although varobj_update
   _does_ behave as expected for frozen children).

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.

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.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [MI] frozen variable objects (bug)

[Vladimir Prus]

Nick Roberts wrote:

> 
> In principle, if a variable object is frozen, print_varobj prints it's
> state out with:
> 
>   if (varobj_get_frozen (var))
>     ui_out_field_int (uiout, "frozen", 1);
> 
> In practice this never happens because print_varobj is called
> 
> a) from -var-create, in which case the object can only be frozen _after_
> it
>   is created.

Yes. The intention is that future patches will cause varobjs to be created
frozen in some cases, without explicit commands from gdb. Said patches
got stuck, unfortunately. 

> 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.

> 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. 

> 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?

- Volodya

 

Re: [MI] frozen variable objects (bug)

[Nick Roberts]

 > > 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
  ^^^^^^^^^^

 > > 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".


> 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.  Maybe frozen objects
are helpful for some intermediate situation but I've never it experienced it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [MI] frozen variable objects (bug)

[Vladimir Prus]

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

Re: [MI] frozen variable objects (bug)

[Nick Roberts]

 > > 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).

No it's not.  The fact that I haven't seen a need for them is not really
a case for not having them.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [MI] frozen variable objects (bug)

[Daniel Jacobowitz]

On Wed, Jun 27, 2007 at 11:46:29AM +0400, Vladimir Prus wrote:
> 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?

Same reason a front end would want to freeze a variable object;
sometimes it's more convenient one way, sometimes another way.
If we're calling this an attribute, I think -var-show-attributes
should display it.

-- 
Daniel Jacobowitz
CodeSourcery