Re: MI: frozen variable objects

[Greg Watson <g.watson@computer.org>]

I don't really understand the motivation for putting this kind of  
functionality into gdb. Any GUI that is more than just a front-end  
for gdb will most likely have an internal data structure representing  
the value of the variable, and can retain or manage access to the  
value if required. It seems to me that adding functionality like this  
to gdb just adds to bloat when it is really a GUI function anyway.

Greg

On Nov 16, 2006, at 5:47 AM, Vladimir Prus wrote:

>
> This patch introduces so called "frozen" variable objects --  
> variable objects
> that are not implicitly updated by the "-var-update *" command or by
> "-var-update" on parent variable objects.
>
> Those are needed in two cases:
>
>     - GUI might want to capture a value of some variable in the  
> program
>     and don't update it automatically. For example, so that at a  
> later point
>     you can look at the current values, and compare them with  
> previous values.
>     Now, MI does not provide any mechanism to do it.
>
>     - Some values might be "read-sensitive" -- it might be some  
> memory-mapped
>     hardware register and reading from it will extact data from  
> FIFO, or
>     acknowledge an interrupt, so this is not something that can be  
> done
>     implicitly.
>
> Frozen variable object is a mechanism to handle those use cases.  
> The most
> important design aspects are:
>
>    - A variable object can be made frozen either by explicit  
> request from the
>     user, or automatically by gdb, if gdb detect that the value is
>     read-sensitive. The present patch does not implement such auto- 
> detection
>     but I'm prototyped such functionality too, and it will be  
> coming later.
>
>    - If a variable object is frozen, then the value of that object,  
> or any
>      children of it, will be fetched from the memory (via  
> value_fetch_lazy)
>      only by explicit -var-update for that variable object or a  
> child. No
>      other operations, importantly -var-update * and -var-update of  
> parents
>      of frozen variable object, and -var-list-children, will fetch  
> the value.
>
>    - It is possible that a frozen variable has no value fetched. In  
> that
>     case -var-evaluate-expression will return empty string -- it won't
>     implicitly fetch the value.
>
> The patch is not fully finished -- it does not include testcase  
> changes, and
> it does not include docs. Both will take quite some time, so I'd  
> like to pass
> the code patch itself for review first.
>
> Thanks,
> Volodya
>
> 	* varobj.h (varobj_set_frozen): New
> 	(varobj_get_frozen): New.
> 	(varobj_update): New parameter explicit.
> 	* varobj.c (struct varobj): New fields frozen
> 	and not_fetched.
> 	(varobj_set_frozen, varobj_get_frozen): New.
> 	(install_new_value): Don't fetch values for
> 	frozen variable object, or children thereof.  Allow
> 	a frozen variable object to have non-fetched value.
> 	(varobj_update): Allow updating child variables.
> 	Don't traverse frozen children.
> 	(new_variable): Initialize the frozen field.
> 	(c_value_of_variable): Return NULL for frozen
> 	variable without any value yet.
> 	* mi/mi-cmd-var.c (varobj_update_one): New parameter
> 	'explicit'.
> 	(mi_cmd_var_create): Output the 'frozen' field,
> 	as soon as testsuite is adjusted to expect that field.
> 	(mi_cmd_var_set_frozen): New.
> 	(mi_cmd_var_list_children): : Output the 'frozen' field,
> 	as soon as testsuite is adjusted to expect that field.
> 	(mi_cmd_var_update): Pass the 'explicit' parameter to
> 	varobj_update_one.
> 	* mi/mi-cmds.c (mi_cmds): Register '-var-set-frozen'.
> 	* mi/mi-cmds.h (mi_cmd_var_set_frozen): Declare.
> <frozen.diff>