This is the mail archive of the gdb-patches@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


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>


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