Ping: frozen variable objects

Vladimir Prus vladimir@codesourcery.com
Wed Apr 11 14:44:00 GMT 2007


On Tuesday 10 April 2007 23:03, Daniel Jacobowitz wrote:
> On Sun, Mar 25, 2007 at 12:51:42PM +0300, Vladimir Prus wrote:
> > --- gdb/doc/gdb.texinfo	(/mirrors/gdb_mainline)	(revision 3540)
> > +++ gdb/doc/gdb.texinfo	(/patches/gdb/frozen/gdb_mainline)	(revision 3540)
> > @@ -19730,6 +19730,8 @@ access this functionality:
> >  @tab set the value of this variable
> >  @item @code{-var-update}
> >  @tab update the variable and its children
> > +@item @code{-var-set-frozen}
> > +@tab set frozeness attribute
> >  @end multitable
> >  
> >  In the next subsection we describe each operation in detail and suggest
> 
> Hmm, that line at the bottom says there's detailed documentation
> below.  But you didn't add any for -var-set-frozen.

Wierd, that docs were in previous patch. I've revived them now.

> There's also this:
> 
> > +  if (varobj_get_frozen (var))
> > +    ui_out_field_int (uiout, "frozen", 1);
> 
> Somewhere in the manual should mention how that can happen, and what
> it means.

I'm not sure where this can be documented. Varobj can be printed
either by -var-create or by -var-update, and we have no common
list of attributes of varobj anywhere.

> > +      if (frozen && initial)
> > +	{
> > +	  /* For variables that are frozen, or are children of frozen
> > +	     variables, we don't do fetch on initial assignment.
> > +	     For non-initial assignemnt we do the fetch, since it means we're
> > +	     explicitly asked to compare the new value with the old one.  */
> > +	  intentionally_not_fetched = 1;
> > +	}
> 
> Does this mean "-var-assign VAR value" is always going to read VAR?
> If it's frozen that seems undesirable; maybe we should just assume
> it's been updated.

I think that now that varobjs are never created frozen, we don't have
this problem -- as you'll have have varobj with lazy, non-fetched value.

With register browsing added, the varobj can be created frozen,
with lazy, non-fetched value, that might be a problem. However, I think
the right way to fix that problem would be to make sure that value_assign
never returns lazy non-fetched value. After all we've just assigned a value
so we can mark value as fetched....

> For hardware mapped registers, some of this may not be right: I
> noticed that we're saving the installed value, but the hardware could
> swizzle it as it is entered.  The most common place this happens is
> with registers where a bit always reads as zero, no matter what you
> write to it.  

Probably that's OK. If user wants to see what the value is really there
in hardware, he can read the value again.

I attach revised patch, except for "frozen" attribute docs, and -var-assign
changes.

- Volodya
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frozen2__gdb_mainline.diff
Type: text/x-diff
Size: 22718 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20070411/b71ae071/attachment.bin>
-------------- next part --------------
        gdb/
	* 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_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.

        doc/
        * gdb.texinfo (GDB/MI Variable Objects): Document
	frozen variables objects.

        testsuite/
	* gdb.mi/mi-var-cmd.exp: Delete varobjs left by previous
	tests. Run the frozen varobjs test.
	* gdb.mi/var-cmd.c (do_frozen_tests): New.
	* lib/mi-support.exp (mi_varobj_delete): New.
	(mi_varobj_update): Fix thinko.


More information about the Gdb-patches mailing list