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