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