This is the mail archive of the 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)

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


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