* Ping: frozen variable objects
@ 2007-03-25 9:52 Vladimir Prus
2007-03-25 20:17 ` Eli Zaretskii
2007-04-10 19:03 ` Daniel Jacobowitz
0 siblings, 2 replies; 33+ messages in thread
From: Vladimir Prus @ 2007-03-25 9:52 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 213 bytes --]
The frozen variable objects patch:
http://thread.gmane.org/gmane.comp.gdb.patches/31838
seem to be unreviewed as yet. Here's a version that's
updated for the current mainline, no regressions. OK?
- Volodya
[-- Attachment #2: frozen.ChangeLog --]
[-- Type: text/plain, Size: 1312 bytes --]
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.
[-- Attachment #3: frozen__gdb_mainline.diff --]
[-- Type: text/x-diff, Size: 22063 bytes --]
--- 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
--- gdb/testsuite/gdb.mi/mi-var-cmd.exp (/mirrors/gdb_mainline) (revision 3540)
+++ gdb/testsuite/gdb.mi/mi-var-cmd.exp (/patches/gdb/frozen/gdb_mainline) (revision 3540)
@@ -591,6 +591,20 @@ mi_gdb_test "-var-update selected_a" \
"\\^done,changelist=\\\[\{name=\"selected_a\",in_scope=\"true\",new_type=\"int\",new_num_children=\"0\"\}\\\]" \
"update selected_a in do_special_tests"
+mi_delete_varobj selected_a "delete selected_a"
+mi_delete_varobj array_ptr "delete array_ptr"
+
+proc set_frozen {varobjs flag} {
+ foreach v $varobjs {
+ mi_gdb_test "-var-set-frozen $v $flag" \
+ "\\^done" \
+ "-var-set-frozen $v $flag"
+ }
+}
+
+mi_prepare_inline_tests $srcfile
+mi_run_inline_test frozen
+
# Test whether bad varobjs crash GDB.
# A varobj we fail to read during -var-update should be considered
--- gdb/testsuite/gdb.mi/var-cmd.c (/mirrors/gdb_mainline) (revision 3540)
+++ gdb/testsuite/gdb.mi/var-cmd.c (/patches/gdb/frozen/gdb_mainline) (revision 3540)
@@ -315,6 +315,92 @@ do_special_tests (void)
incr_a(2);
}
+void do_frozen_tests ()
+{
+ /*: BEGIN: frozen :*/
+ struct {
+ int i;
+ struct {
+ int j;
+ int k;
+ } nested;
+ } v1 = {1, {2, 3}};
+
+ int v2 = 4;
+ /*:
+ mi_create_varobj V1 v1 "create varobj for v1"
+ mi_create_varobj V2 v2 "create varobj for v2"
+
+ mi_list_varobj_children "V1" {
+ {"V1.i" "i" "0" "int"}
+ {"V1.nested" "nested" "2" "struct {...}"}
+ } "list children of v1"
+
+ mi_list_varobj_children "V1.nested" {
+ {"V1.nested.j" "j" "0" "int"}
+ {"V1.nested.k" "k" "0" "int"}
+ } "list children of v1.nested"
+
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 2 "check V1.nested.j: 2"
+ mi_check_varobj_value V1.nested.k 3 "check V1.nested.j: 3"
+ mi_check_varobj_value V2 4 "check V2: 4"
+ :*/
+ v2 = 5;
+ /*:
+ mi_varobj_update * {V2} "update varobjs: V2 changed"
+ set_frozen V2 1
+ :*/
+ v2 = 6;
+ /*:
+ mi_varobj_update * {} "update varobjs: nothing changed"
+ mi_check_varobj_value V2 5 "check V2: 5"
+ mi_varobj_update V2 {V2} "update V2 explicitly"
+ mi_check_varobj_value V2 6 "check V2: 6"
+ :*/
+ v1.i = 7;
+ v1.nested.j = 8;
+ v1.nested.k = 9;
+ /*:
+ set_frozen V1 1
+ mi_varobj_update * {} "update varobjs: nothing changed"
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 2 "check V1.nested.j: 2"
+ mi_check_varobj_value V1.nested.k 3 "check V1.nested.j: 3"
+ # Check that explicit update for elements of structures
+ # works.
+ # Update v1.j
+ mi_varobj_update V1.nested.j {V1.nested.j} "update V1.nested.j"
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 8 "check V1.nested.j: 8"
+ mi_check_varobj_value V1.nested.k 3 "check V1.nested.j: 3"
+ # Update v1.nested, check that children is updated.
+ mi_varobj_update V1.nested {V1.nested.k} "update V1.nested"
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 8 "check V1.nested.j: 8"
+ mi_check_varobj_value V1.nested.k 9 "check V1.nested.j: 9"
+ # Update v1.i
+ mi_varobj_update V1.i {V1.i} "update V1.i"
+ mi_check_varobj_value V1.i 7 "check V1.i: 7"
+ :*/
+ v1.i = 10;
+ v1.nested.j = 11;
+ v1.nested.k = 12;
+ /*:
+ # Check that unfreeze itself does not updates the values.
+ set_frozen V1 0
+ mi_check_varobj_value V1.i 7 "check V1.i: 7"
+ mi_check_varobj_value V1.nested.j 8 "check V1.nested.j: 8"
+ mi_check_varobj_value V1.nested.k 9 "check V1.nested.j: 9"
+ mi_varobj_update V1 {V1.i V1.nested.j V1.nested.k} "update V1"
+ mi_check_varobj_value V1.i 10 "check V1.i: 10"
+ mi_check_varobj_value V1.nested.j 11 "check V1.nested.j: 11"
+ mi_check_varobj_value V1.nested.k 12 "check V1.nested.j: 12"
+ :*/
+
+ /*: END: frozen :*/
+}
+
int
main (int argc, char *argv [])
{
@@ -322,6 +408,7 @@ main (int argc, char *argv [])
do_block_tests ();
do_children_tests ();
do_special_tests ();
+ do_frozen_tests ();
exit (0);
}
--- gdb/testsuite/lib/mi-support.exp (/mirrors/gdb_mainline) (revision 3540)
+++ gdb/testsuite/lib/mi-support.exp (/patches/gdb/frozen/gdb_mainline) (revision 3540)
@@ -1039,8 +1039,9 @@ proc mi_varobj_update { name expected te
set first 1
foreach item $expected {
set v "{name=\"$item\",in_scope=\"true\",type_changed=\"false\"}"
- if {$first} {
+ if {$first == 1} {
set er "$er$v"
+ set first 0
} else {
set er "$er,$v"
}
@@ -1239,11 +1240,11 @@ proc mi_send_resuming_command {command t
# be determined.
# Does not check that the line is the same as requested.
# The caller can check itself if required.
-proc mi_continue_to_line {location command} {
+proc mi_continue_to_line {location} {
mi_tbreak $location
mi_send_resuming_command "exec-continue" "run to $location (exec-continue)"
- return [mi_wait_for_stop]
+ return [mi_wait_for_stop "continue to $location"]
}
# Wait until gdb prints the current line.
Property changes on: gdb/testsuite/lib
___________________________________________________________________
Name: svk:merge
+d48a11ec-ee1c-0410-b3f5-c20844f99675:/patches/gdb/frozen/gdb_mainline/gdb/testsuite/lib:2741
--- gdb/mi/mi-cmds.h (/mirrors/gdb_mainline) (revision 3540)
+++ gdb/mi/mi-cmds.h (/patches/gdb/frozen/gdb_mainline) (revision 3540)
@@ -113,6 +113,7 @@ extern mi_cmd_argv_ftype mi_cmd_var_info
extern mi_cmd_argv_ftype mi_cmd_var_info_type;
extern mi_cmd_argv_ftype mi_cmd_var_list_children;
extern mi_cmd_argv_ftype mi_cmd_var_set_format;
+extern mi_cmd_argv_ftype mi_cmd_var_set_frozen;
extern mi_cmd_argv_ftype mi_cmd_var_show_attributes;
extern mi_cmd_argv_ftype mi_cmd_var_show_format;
extern mi_cmd_argv_ftype mi_cmd_var_update;
--- gdb/mi/mi-cmds.c (/mirrors/gdb_mainline) (revision 3540)
+++ gdb/mi/mi-cmds.c (/patches/gdb/frozen/gdb_mainline) (revision 3540)
@@ -156,6 +156,7 @@ struct mi_cmd mi_cmds[] =
{ "var-info-type", { NULL, 0 }, 0, mi_cmd_var_info_type},
{ "var-list-children", { NULL, 0 }, 0, mi_cmd_var_list_children},
{ "var-set-format", { NULL, 0 }, 0, mi_cmd_var_set_format},
+ { "var-set-frozen", { NULL, 0 }, 0, mi_cmd_var_set_frozen},
{ "var-show-attributes", { NULL, 0 }, 0, mi_cmd_var_show_attributes},
{ "var-show-format", { NULL, 0 }, 0, mi_cmd_var_show_format},
{ "var-update", { NULL, 0 }, 0, mi_cmd_var_update},
--- gdb/mi/mi-cmd-var.c (/mirrors/gdb_mainline) (revision 3540)
+++ gdb/mi/mi-cmd-var.c (/patches/gdb/frozen/gdb_mainline) (revision 3540)
@@ -37,7 +37,8 @@ const char mi_all_values[] = "--all-valu
extern int varobjdebug; /* defined in varobj.c. */
static void varobj_update_one (struct varobj *var,
- enum print_values print_values);
+ enum print_values print_values,
+ int explicit);
static int mi_print_value_p (struct type *type, enum print_values print_values);
@@ -64,6 +65,9 @@ print_varobj (struct varobj *var, enum p
ui_out_field_string (uiout, "type", type);
xfree (type);
}
+
+ if (varobj_get_frozen (var))
+ ui_out_field_int (uiout, "frozen", 1);
}
/* VAROBJ operations */
@@ -233,6 +237,35 @@ mi_cmd_var_set_format (char *command, ch
}
enum mi_cmd_result
+mi_cmd_var_set_frozen (char *command, char **argv, int argc)
+{
+ struct varobj *var;
+ int frozen;
+
+ if (argc != 2)
+ error (_("mi_cmd_var_set_format: Usage: NAME FROZEN_FLAG."));
+
+ var = varobj_get_handle (argv[0]);
+ if (var == NULL)
+ error (_("Variable object not found"));
+
+ if (strcmp (argv[1], "0") == 0)
+ frozen = 0;
+ else if (strcmp (argv[1], "1") == 0)
+ frozen = 1;
+ else
+ error (_("Invalid flag value"));
+
+ varobj_set_frozen (var, frozen);
+
+ /* We don't automatically return the new value, or what varobjs got new
+ values during unfreezing. If this information is required, client
+ should call -var-update explicitly. */
+ return MI_CMD_DONE;
+}
+
+
+enum mi_cmd_result
mi_cmd_var_show_format (char *command, char **argv, int argc)
{
enum varobj_display_formats format;
@@ -513,7 +546,7 @@ mi_cmd_var_update (char *command, char *
cr = rootlist;
while (*cr != NULL)
{
- varobj_update_one (*cr, print_values);
+ varobj_update_one (*cr, print_values, 0 /* implicit */);
cr++;
}
do_cleanups (cleanup);
@@ -529,7 +562,7 @@ mi_cmd_var_update (char *command, char *
cleanup = make_cleanup_ui_out_tuple_begin_end (uiout, "changelist");
else
cleanup = make_cleanup_ui_out_list_begin_end (uiout, "changelist");
- varobj_update_one (var, print_values);
+ varobj_update_one (var, print_values, 1 /* explicit */);
do_cleanups (cleanup);
}
return MI_CMD_DONE;
@@ -538,14 +571,15 @@ mi_cmd_var_update (char *command, char *
/* Helper for mi_cmd_var_update(). */
static void
-varobj_update_one (struct varobj *var, enum print_values print_values)
+varobj_update_one (struct varobj *var, enum print_values print_values,
+ int explicit)
{
struct varobj **changelist;
struct varobj **cc;
struct cleanup *cleanup = NULL;
int nc;
- nc = varobj_update (&var, &changelist);
+ nc = varobj_update (&var, &changelist, explicit);
/* nc >= 0 represents the number of changes reported into changelist.
nc < 0 means that an error occured or the the variable has
--- gdb/varobj.c (/mirrors/gdb_mainline) (revision 3540)
+++ gdb/varobj.c (/patches/gdb/frozen/gdb_mainline) (revision 3540)
@@ -137,6 +137,16 @@ struct varobj
/* Last print value. */
char *print_value;
+
+ /* Is this variable frozen. Frozen variables are never implicitly
+ updated by -var-update * or -var-update <direct-or-indirect-parent>.
+ */
+ int frozen;
+
+ /* Is the value of this variable intentionally not fetched? It is
+ not fetched if either the variable is frozen, or any parents is
+ frozen. */
+ int not_fetched;
};
struct cpstack
@@ -665,6 +675,26 @@ varobj_get_display_format (struct varobj
return var->format;
}
+void
+varobj_set_frozen (struct varobj *var, int frozen)
+{
+ /* When a variable is unfrozen, we don't fetch its value.
+ The 'not_fetched' flag remains set, so next -var-update
+ won't complain.
+
+ We don't fetch the value, because for structures the client
+ should do -var-update anyway. It would be bad to have different
+ client-size logic for structure and other types. */
+ var->frozen = frozen;
+}
+
+int
+varobj_get_frozen (struct varobj *var)
+{
+ return var->frozen;
+}
+
+
int
varobj_get_num_children (struct varobj *var)
{
@@ -911,6 +941,7 @@ install_new_value (struct varobj *var, s
int changeable;
int need_to_fetch;
int changed = 0;
+ int intentionally_not_fetched = 0;
/* We need to know the varobj's type to decide if the value should
be fetched or not. C++ fake children (public/protected/private) don't have
@@ -943,10 +974,23 @@ install_new_value (struct varobj *var, s
/* The new value might be lazy. If the type is changeable,
that is we'll be comparing values of this type, fetch the
value now. Otherwise, on the next update the old value
- will be lazy, which means we've lost that old value. */
+ will be lazy, which means we've lost that old value. */
if (need_to_fetch && value && value_lazy (value))
{
- if (!gdb_value_fetch_lazy (value))
+ struct varobj *parent = var->parent;
+ int frozen = var->frozen;
+ for (; !frozen && parent; parent = parent->parent)
+ frozen |= parent->frozen;
+
+ 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;
+ }
+ else if (!gdb_value_fetch_lazy (value))
{
/* Set the value to NULL, so that for the next -var-update,
we don't try to compare the new value with this value,
@@ -976,41 +1020,56 @@ install_new_value (struct varobj *var, s
{
/* Try to compare the values. That requires that both
values are non-lazy. */
-
- /* Quick comparison of NULL values. */
- if (var->value == NULL && value == NULL)
- /* Equal. */
- ;
- else if (var->value == NULL || value == NULL)
+ if (var->not_fetched && value_lazy (var->value))
{
- xfree (var->print_value);
- var->print_value = value_get_print_value (value, var->format);
+ /* This is a frozen varobj and the value was never read.
+ Presumably, UI shows some "never read" indicator.
+ Now that we've fetched the real value, we need to report
+ this varobj as changed so that UI can show the real
+ value. */
changed = 1;
}
- else
+ else
{
- char *print_value;
- gdb_assert (!value_lazy (var->value));
- gdb_assert (!value_lazy (value));
- print_value = value_get_print_value (value, var->format);
-
- gdb_assert (var->print_value != NULL && print_value != NULL);
- if (strcmp (var->print_value, print_value) != 0)
+ /* Quick comparison of NULL values. */
+ if (var->value == NULL && value == NULL)
+ /* Equal. */
+ ;
+ else if (var->value == NULL || value == NULL)
{
xfree (var->print_value);
- var->print_value = print_value;
+ var->print_value = value_get_print_value (value, var->format);
changed = 1;
}
else
- xfree (print_value);
+ {
+ char *print_value;
+ gdb_assert (!value_lazy (var->value));
+ gdb_assert (!value_lazy (value));
+ print_value = value_get_print_value (value, var->format);
+
+ gdb_assert (var->print_value != NULL && print_value != NULL);
+ if (strcmp (var->print_value, print_value) != 0)
+ {
+ xfree (var->print_value);
+ var->print_value = print_value;
+ changed = 1;
+ }
+ else
+ xfree (print_value);
+ }
}
}
}
/* We must always keep the new value, since children depend on it. */
- if (var->value != NULL)
+ if (var->value != NULL && var->value != value)
value_free (var->value);
var->value = value;
+ if (value && value_lazy (value) && intentionally_not_fetched)
+ var->not_fetched = 1;
+ else
+ var->not_fetched = 0;
var->updated = 0;
gdb_assert (!var->value || value_type (var->value));
@@ -1027,17 +1086,21 @@ install_new_value (struct varobj *var, s
< 0 for error values, see varobj.h.
Otherwise it is the number of children + parent changed.
- Only root variables can be updated...
+ The EXPLICIT parameter specifies if this call is result
+ of MI request to update this specific variable, or
+ result of implicit -var-update *. For implicit request, we don't
+ update frozen variables.
NOTE: This function may delete the caller's varobj. If it
returns TYPE_CHANGED, then it has done this and VARP will be modified
to point to the new varobj. */
int
-varobj_update (struct varobj **varp, struct varobj ***changelist)
+varobj_update (struct varobj **varp, struct varobj ***changelist,
+ int explicit)
{
int changed = 0;
- int type_changed;
+ int type_changed = 0;
int i;
int vleft;
struct varobj *v;
@@ -1052,48 +1115,56 @@ varobj_update (struct varobj **varp, str
/* sanity check: have we been passed a pointer? */
gdb_assert (changelist);
- if (!is_root_p (*varp))
- error (_("Only root variables can be updated"));
+ /* Frozen means frozen -- we don't check for any change in
+ this varobj, including its going out of scope, or
+ changing type. One use case for frozen varobjs is
+ retaining previously evaluated expressions, and we don't
+ want them to be reevaluated at all. */
+ if (!explicit && (*varp)->frozen)
+ return 0;
if (!(*varp)->root->is_valid)
return INVALID;
- /* Save the selected stack frame, since we will need to change it
- in order to evaluate expressions. */
- old_fid = get_frame_id (deprecated_safe_get_selected_frame ());
-
- /* Update the root variable. value_of_root can return NULL
- if the variable is no longer around, i.e. we stepped out of
- the frame in which a local existed. We are letting the
- value_of_root variable dispose of the varobj if the type
- has changed. */
- type_changed = 1;
- new = value_of_root (varp, &type_changed);
-
- /* Restore selected frame. */
- fi = frame_find_by_id (old_fid);
- if (fi)
- select_frame (fi);
-
- /* If this is a "use_selected_frame" varobj, and its type has changed,
- them note that it's changed. */
- if (type_changed)
- VEC_safe_push (varobj_p, result, *varp);
-
- if (install_new_value ((*varp), new, type_changed))
+ if ((*varp)->root->rootvar == *varp)
{
- /* If type_changed is 1, install_new_value will never return
- non-zero, so we'll never report the same variable twice. */
- gdb_assert (!type_changed);
- VEC_safe_push (varobj_p, result, *varp);
- }
+ /* Save the selected stack frame, since we will need to change it
+ in order to evaluate expressions. */
+ old_fid = get_frame_id (deprecated_safe_get_selected_frame ());
+
+ /* Update the root variable. value_of_root can return NULL
+ if the variable is no longer around, i.e. we stepped out of
+ the frame in which a local existed. We are letting the
+ value_of_root variable dispose of the varobj if the type
+ has changed. */
+ type_changed = 1;
+ new = value_of_root (varp, &type_changed);
- if (new == NULL)
- {
- /* This means the varobj itself is out of scope.
- Report it. */
- VEC_free (varobj_p, result);
- return NOT_IN_SCOPE;
+ /* Restore selected frame. */
+ fi = frame_find_by_id (old_fid);
+ if (fi)
+ select_frame (fi);
+
+ /* If this is a "use_selected_frame" varobj, and its type has changed,
+ them note that it's changed. */
+ if (type_changed)
+ VEC_safe_push (varobj_p, result, *varp);
+
+ if (install_new_value ((*varp), new, type_changed))
+ {
+ /* If type_changed is 1, install_new_value will never return
+ non-zero, so we'll never report the same variable twice. */
+ gdb_assert (!type_changed);
+ VEC_safe_push (varobj_p, result, *varp);
+ }
+
+ if (new == NULL)
+ {
+ /* This means the varobj itself is out of scope.
+ Report it. */
+ VEC_free (varobj_p, result);
+ return NOT_IN_SCOPE;
+ }
}
VEC_safe_push (varobj_p, stack, *varp);
@@ -1111,13 +1182,13 @@ varobj_update (struct varobj **varp, str
{
varobj_p c = VEC_index (varobj_p, v->children, i);
/* Child may be NULL if explicitly deleted by -var-delete. */
- if (c != NULL)
+ if (c != NULL && !c->frozen)
VEC_safe_push (varobj_p, stack, c);
}
-
+
/* Update this variable, unless it's a root, which is already
updated. */
- if (v != *varp)
+ if (v->root->rootvar != v)
{
new = value_of_child (v->parent, v->index);
if (install_new_value (v, new, 0 /* type not changed */))
@@ -1399,6 +1470,8 @@ new_variable (void)
var->root = NULL;
var->updated = 0;
var->print_value = NULL;
+ var->frozen = 0;
+ var->not_fetched = 0;
return var;
}
@@ -2112,6 +2185,12 @@ c_value_of_variable (struct varobj *var)
}
else
{
+ if (var->not_fetched && value_lazy (var->value))
+ /* Frozen variable and no value yet. We don't
+ implicitly fetch the value. MI response will
+ use empty string for the value, which is OK. */
+ return NULL;
+
gdb_assert (varobj_value_is_changeable_p (var));
gdb_assert (!value_lazy (var->value));
return value_get_print_value (var->value, var->format);
@@ -2306,7 +2385,7 @@ cplus_describe_child (struct varobj *par
if (cvalue && value)
{
- *cvalue = value_cast (TYPE_FIELD_TYPE (type, index), value);
+ *cvalue = value_cast (TYPE_FIELD_TYPE (type, index), value);
}
if (ctype)
--- gdb/varobj.h (/mirrors/gdb_mainline) (revision 3540)
+++ gdb/varobj.h (/patches/gdb/frozen/gdb_mainline) (revision 3540)
@@ -86,6 +86,10 @@ extern enum varobj_display_formats varob
extern enum varobj_display_formats varobj_get_display_format (
struct varobj *var);
+extern void varobj_set_frozen (struct varobj *var, int frozen);
+
+extern int varobj_get_frozen (struct varobj *var);
+
extern int varobj_get_num_children (struct varobj *var);
extern int varobj_list_children (struct varobj *var,
@@ -105,7 +109,8 @@ extern int varobj_set_value (struct varo
extern int varobj_list (struct varobj ***rootlist);
-extern int varobj_update (struct varobj **varp, struct varobj ***changelist);
+extern int varobj_update (struct varobj **varp, struct varobj ***changelist,
+ int explicit);
extern void varobj_invalidate (void);
Property changes on:
___________________________________________________________________
Name: csl:base
+/all/mirrors/gdb_mainline
Name: svk:merge
+d48a11ec-ee1c-0410-b3f5-c20844f99675:/patches/gdb/mi_continue_to/gdb_mainline:2736
+d48a11ec-ee1c-0410-b3f5-c20844f99675:/patches/gdb/mi_inline_tests/gdb_mainline:3051
+d48a11ec-ee1c-0410-b3f5-c20844f99675:/patches/gdb/varobj_doc/gdb_mainline:3074
+e7755896-6108-0410-9592-8049d3e74e28:/mirrors/gdb/trunk:166548
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-03-25 9:52 Ping: frozen variable objects Vladimir Prus
@ 2007-03-25 20:17 ` Eli Zaretskii
2007-04-10 19:03 ` Daniel Jacobowitz
1 sibling, 0 replies; 33+ messages in thread
From: Eli Zaretskii @ 2007-03-25 20:17 UTC (permalink / raw)
To: Vladimir Prus; +Cc: gdb-patches
> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Sun, 25 Mar 2007 12:51:42 +0300
>
> The frozen variable objects patch:
>
> http://thread.gmane.org/gmane.comp.gdb.patches/31838
>
> seem to be unreviewed as yet. Here's a version that's
> updated for the current mainline, no regressions. OK?
If the code is approved, you have my blessing for the doco patch.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-03-25 9:52 Ping: frozen variable objects Vladimir Prus
2007-03-25 20:17 ` Eli Zaretskii
@ 2007-04-10 19:03 ` Daniel Jacobowitz
2007-04-11 14:44 ` Vladimir Prus
2007-04-18 5:38 ` Ping: frozen variable objects Michael Snyder
1 sibling, 2 replies; 33+ messages in thread
From: Daniel Jacobowitz @ 2007-04-10 19:03 UTC (permalink / raw)
To: Vladimir Prus; +Cc: gdb-patches
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.
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.
> + mi_check_varobj_value V1.nested.j 2 "check V1.nested.j: 2"
> + mi_check_varobj_value V1.nested.k 3 "check V1.nested.j: 3"
> + # Check that explicit update for elements of structures
> + # works.
> + # Update v1.j
> + mi_varobj_update V1.nested.j {V1.nested.j} "update V1.nested.j"
> + mi_check_varobj_value V1.i 1 "check V1.i: 1"
> + mi_check_varobj_value V1.nested.j 8 "check V1.nested.j: 8"
> + mi_check_varobj_value V1.nested.k 3 "check V1.nested.j: 3"
> + # Update v1.nested, check that children is updated.
> + mi_varobj_update V1.nested {V1.nested.k} "update V1.nested"
> + mi_check_varobj_value V1.i 1 "check V1.i: 1"
> + mi_check_varobj_value V1.nested.j 8 "check V1.nested.j: 8"
> + mi_check_varobj_value V1.nested.k 9 "check V1.nested.j: 9"
You've got a bunch of .j's in the test names that ought to be .k's.
Happens some more below.
> + if (argc != 2)
> + error (_("mi_cmd_var_set_format: Usage: NAME FROZEN_FLAG."));
I think we decided this should be "-var-set-format:" instead of the
function name.
> + /* Is this variable frozen. Frozen variables are never implicitly
> + updated by -var-update * or -var-update <direct-or-indirect-parent>.
> + */
Spaces between sentences, and */ on a line by itself - this is one of
the awkward bits of our formatting standards when the */ doesn't quite
fit on the previous line but I usually just wrap early. I think
emacs's M-q will too.
> @@ -943,10 +974,23 @@ install_new_value (struct varobj *var, s
> /* The new value might be lazy. If the type is changeable,
> that is we'll be comparing values of this type, fetch the
> value now. Otherwise, on the next update the old value
> - will be lazy, which means we've lost that old value. */
> + will be lazy, which means we've lost that old value. */
This added a bunch of trailing whitespace to the line for some reason.
> + 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.
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. But that's a read-sensitivity problem, not a frozen
varobjs problem.
> -
> - /* Quick comparison of NULL values. */
> - if (var->value == NULL && value == NULL)
> - /* Equal. */
> - ;
> - else if (var->value == NULL || value == NULL)
> + if (var->not_fetched && value_lazy (var->value))
> {
> - xfree (var->print_value);
> - var->print_value = value_get_print_value (value, var->format);
> + /* This is a frozen varobj and the value was never read.
> + Presumably, UI shows some "never read" indicator.
> + Now that we've fetched the real value, we need to report
> + this varobj as changed so that UI can show the real
> + value. */
> changed = 1;
> }
> - else
> + else
> {
You don't actually need to change the nesting here. You can just add
a leading if to the existing if / else if / else. That'd be easier to read.
> if (cvalue && value)
> {
> - *cvalue = value_cast (TYPE_FIELD_TYPE (type, index), value);
> + *cvalue = value_cast (TYPE_FIELD_TYPE (type, index), value);
> }
Random tab damage?
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-10 19:03 ` Daniel Jacobowitz
@ 2007-04-11 14:44 ` Vladimir Prus
2007-04-11 14:52 ` Daniel Jacobowitz
2007-04-13 9:53 ` Eli Zaretskii
2007-04-18 5:38 ` Ping: frozen variable objects Michael Snyder
1 sibling, 2 replies; 33+ messages in thread
From: Vladimir Prus @ 2007-04-11 14:44 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 2676 bytes --]
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
[-- Attachment #2: frozen2__gdb_mainline.diff --]
[-- Type: text/x-diff, Size: 22718 bytes --]
--- gdb/doc/gdb.texinfo (/mirrors/gdb_mainline) (revision 3769)
+++ gdb/doc/gdb.texinfo (/patches/gdb/frozen2/gdb_mainline) (revision 3769)
@@ -19536,7 +19536,10 @@ that corresponds to a composite type, su
a number of child variable objects, for example corresponding to each
element of a structure. A child variable object can itself have
children, recursively. Recursion ends when we reach
-leaf variable objects, which always have built-in types.
+leaf variable objects, which always have built-in types. Child variable
+objects are created only by explicit request, so if a frontend
+is not interested in children of a particular variable object, no
+child will be created.
For a leaf variable object it is possible to obtain its value as a
string, or set the value from a string. String value can be also
@@ -19548,7 +19551,19 @@ A frontend does not need to read the val
the program stops. Instead, MI provides an update command that lists all
variable objects whose values has changed since the last update
operation. This considerably reduces the amount of data that must
-be transferred to the frontend.
+be transferred to the frontend. As noted above, children variable
+objects are created on demand, and only leaf variable object have a
+real value. As result, gdb will read target memory only for leaf
+variables that frontend has created.
+
+The automatic update is not always desirable. For example, a frontend
+might want to keep a value of some expression for future reference,
+and never update it. For another example, fetching memory is
+relatively slow for embedded targets, so a frontend might want
+to disable automatic update for the variables that are either not
+visible on the screen, or ``closed''. This is possible using so
+called ``frozen variable objects''. Such variable objects are never
+implicitly updated.
The following is the complete set of @sc{gdb/mi} operations defined to
access this functionality:
@@ -19581,6 +19596,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
@@ -19903,6 +19920,37 @@ objects.
In the future new values may be added to this list so the front should
be prepared for this possibility. @xref{GDB/MI Development and Front Ends, ,@sc{GDB/MI} Development and Front Ends}.
+@subheading The @code{-var-set-frozen} Command
+@findex -var-set-frozen
+
+@subsubheading Synopsis
+
+@smallexample
+ -var-set-frozen @var{name} @samp{flag}
+@end smallexample
+
+Set the frozeness flag on the variable object @var{name}. The
+@samp{flag} parameter should be either @samp{1} to make the variable
+frozen or @samp{0} to make it unfozen. If a variable object is
+frozen, then neither itself, nor any of its children, are
+implicitly updated by @code{-var-update} of a parent variable or
+by @code{-var-update *}. Only
+@code{-var-update} of the variable itself will update its value and
+values of its children. After a variable object is unfrozen, it is
+implicitly updated by all subsequent @code{-var-update} operations.
+Unfreezing a variable does not update it, only subsequent
+@code{-var-update} does.
+
+@subsubheading Example
+
+@smallexample
+(gdb)
+-var-set-frozen V 1
+^done
+(gdb)
+@end smallexample
+
+
@c %%%%%%%%%%%%%%%%%%%%%%%%%%%% SECTION %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@node GDB/MI Data Manipulation
@section @sc{gdb/mi} Data Manipulation
--- gdb/testsuite/gdb.mi/mi-var-cmd.exp (/mirrors/gdb_mainline) (revision 3769)
+++ gdb/testsuite/gdb.mi/mi-var-cmd.exp (/patches/gdb/frozen2/gdb_mainline) (revision 3769)
@@ -596,6 +596,20 @@ mi_gdb_test "-var-update selected_a" \
"\\^done,changelist=\\\[\{name=\"selected_a\",in_scope=\"true\",new_type=\"int\",new_num_children=\"0\"\}\\\]" \
"update selected_a in do_special_tests"
+mi_delete_varobj selected_a "delete selected_a"
+mi_delete_varobj array_ptr "delete array_ptr"
+
+proc set_frozen {varobjs flag} {
+ foreach v $varobjs {
+ mi_gdb_test "-var-set-frozen $v $flag" \
+ "\\^done" \
+ "-var-set-frozen $v $flag"
+ }
+}
+
+mi_prepare_inline_tests $srcfile
+mi_run_inline_test frozen
+
# Test whether bad varobjs crash GDB.
# A varobj we fail to read during -var-update should be considered
--- gdb/testsuite/gdb.mi/var-cmd.c (/mirrors/gdb_mainline) (revision 3769)
+++ gdb/testsuite/gdb.mi/var-cmd.c (/patches/gdb/frozen2/gdb_mainline) (revision 3769)
@@ -315,6 +315,92 @@ do_special_tests (void)
incr_a(2);
}
+void do_frozen_tests ()
+{
+ /*: BEGIN: frozen :*/
+ struct {
+ int i;
+ struct {
+ int j;
+ int k;
+ } nested;
+ } v1 = {1, {2, 3}};
+
+ int v2 = 4;
+ /*:
+ mi_create_varobj V1 v1 "create varobj for v1"
+ mi_create_varobj V2 v2 "create varobj for v2"
+
+ mi_list_varobj_children "V1" {
+ {"V1.i" "i" "0" "int"}
+ {"V1.nested" "nested" "2" "struct {...}"}
+ } "list children of v1"
+
+ mi_list_varobj_children "V1.nested" {
+ {"V1.nested.j" "j" "0" "int"}
+ {"V1.nested.k" "k" "0" "int"}
+ } "list children of v1.nested"
+
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 2 "check V1.nested.j: 2"
+ mi_check_varobj_value V1.nested.k 3 "check V1.nested.k: 3"
+ mi_check_varobj_value V2 4 "check V2: 4"
+ :*/
+ v2 = 5;
+ /*:
+ mi_varobj_update * {V2} "update varobjs: V2 changed"
+ set_frozen V2 1
+ :*/
+ v2 = 6;
+ /*:
+ mi_varobj_update * {} "update varobjs: nothing changed"
+ mi_check_varobj_value V2 5 "check V2: 5"
+ mi_varobj_update V2 {V2} "update V2 explicitly"
+ mi_check_varobj_value V2 6 "check V2: 6"
+ :*/
+ v1.i = 7;
+ v1.nested.j = 8;
+ v1.nested.k = 9;
+ /*:
+ set_frozen V1 1
+ mi_varobj_update * {} "update varobjs: nothing changed"
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 2 "check V1.nested.j: 2"
+ mi_check_varobj_value V1.nested.k 3 "check V1.nested.k: 3"
+ # Check that explicit update for elements of structures
+ # works.
+ # Update v1.j
+ mi_varobj_update V1.nested.j {V1.nested.j} "update V1.nested.j"
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 8 "check V1.nested.j: 8"
+ mi_check_varobj_value V1.nested.k 3 "check V1.nested.k: 3"
+ # Update v1.nested, check that children is updated.
+ mi_varobj_update V1.nested {V1.nested.k} "update V1.nested"
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 8 "check V1.nested.j: 8"
+ mi_check_varobj_value V1.nested.k 9 "check V1.nested.k: 9"
+ # Update v1.i
+ mi_varobj_update V1.i {V1.i} "update V1.i"
+ mi_check_varobj_value V1.i 7 "check V1.i: 7"
+ :*/
+ v1.i = 10;
+ v1.nested.j = 11;
+ v1.nested.k = 12;
+ /*:
+ # Check that unfreeze itself does not updates the values.
+ set_frozen V1 0
+ mi_check_varobj_value V1.i 7 "check V1.i: 7"
+ mi_check_varobj_value V1.nested.j 8 "check V1.nested.j: 8"
+ mi_check_varobj_value V1.nested.k 9 "check V1.nested.k: 9"
+ mi_varobj_update V1 {V1.i V1.nested.j V1.nested.k} "update V1"
+ mi_check_varobj_value V1.i 10 "check V1.i: 10"
+ mi_check_varobj_value V1.nested.j 11 "check V1.nested.j: 11"
+ mi_check_varobj_value V1.nested.k 12 "check V1.nested.k: 12"
+ :*/
+
+ /*: END: frozen :*/
+}
+
int
main (int argc, char *argv [])
{
@@ -322,6 +408,7 @@ main (int argc, char *argv [])
do_block_tests ();
do_children_tests ();
do_special_tests ();
+ do_frozen_tests ();
exit (0);
}
--- gdb/testsuite/lib/mi-support.exp (/mirrors/gdb_mainline) (revision 3769)
+++ gdb/testsuite/lib/mi-support.exp (/patches/gdb/frozen2/gdb_mainline) (revision 3769)
@@ -1024,8 +1024,9 @@ proc mi_varobj_update { name expected te
set first 1
foreach item $expected {
set v "{name=\"$item\",in_scope=\"true\",type_changed=\"false\"}"
- if {$first} {
+ if {$first == 1} {
set er "$er$v"
+ set first 0
} else {
set er "$er,$v"
}
@@ -1312,7 +1313,7 @@ proc mi_run_inline_test { testcase } {
set line_now [mi_wait_for_stop "$testcase: step to $line"]
set first 0
} elseif {$line_now!=$line} {
- set line_now [mi_continue_to_line "$mi_autotest_source:$line"]
+ set line_now [mi_continue_to_line "$mi_autotest_source:$line" "continue to $line"]
}
if {$line_now!=$line} {
--- gdb/mi/mi-cmds.h (/mirrors/gdb_mainline) (revision 3769)
+++ gdb/mi/mi-cmds.h (/patches/gdb/frozen2/gdb_mainline) (revision 3769)
@@ -113,6 +113,7 @@ extern mi_cmd_argv_ftype mi_cmd_var_info
extern mi_cmd_argv_ftype mi_cmd_var_info_type;
extern mi_cmd_argv_ftype mi_cmd_var_list_children;
extern mi_cmd_argv_ftype mi_cmd_var_set_format;
+extern mi_cmd_argv_ftype mi_cmd_var_set_frozen;
extern mi_cmd_argv_ftype mi_cmd_var_show_attributes;
extern mi_cmd_argv_ftype mi_cmd_var_show_format;
extern mi_cmd_argv_ftype mi_cmd_var_update;
--- gdb/mi/mi-cmds.c (/mirrors/gdb_mainline) (revision 3769)
+++ gdb/mi/mi-cmds.c (/patches/gdb/frozen2/gdb_mainline) (revision 3769)
@@ -156,6 +156,7 @@ struct mi_cmd mi_cmds[] =
{ "var-info-type", { NULL, 0 }, 0, mi_cmd_var_info_type},
{ "var-list-children", { NULL, 0 }, 0, mi_cmd_var_list_children},
{ "var-set-format", { NULL, 0 }, 0, mi_cmd_var_set_format},
+ { "var-set-frozen", { NULL, 0 }, 0, mi_cmd_var_set_frozen},
{ "var-show-attributes", { NULL, 0 }, 0, mi_cmd_var_show_attributes},
{ "var-show-format", { NULL, 0 }, 0, mi_cmd_var_show_format},
{ "var-update", { NULL, 0 }, 0, mi_cmd_var_update},
--- gdb/mi/mi-cmd-var.c (/mirrors/gdb_mainline) (revision 3769)
+++ gdb/mi/mi-cmd-var.c (/patches/gdb/frozen2/gdb_mainline) (revision 3769)
@@ -37,7 +37,8 @@ const char mi_all_values[] = "--all-valu
extern int varobjdebug; /* defined in varobj.c. */
static void varobj_update_one (struct varobj *var,
- enum print_values print_values);
+ enum print_values print_values,
+ int explicit);
static int mi_print_value_p (struct type *type, enum print_values print_values);
@@ -64,6 +65,9 @@ print_varobj (struct varobj *var, enum p
ui_out_field_string (uiout, "type", type);
xfree (type);
}
+
+ if (varobj_get_frozen (var))
+ ui_out_field_int (uiout, "frozen", 1);
}
/* VAROBJ operations */
@@ -233,6 +237,35 @@ mi_cmd_var_set_format (char *command, ch
}
enum mi_cmd_result
+mi_cmd_var_set_frozen (char *command, char **argv, int argc)
+{
+ struct varobj *var;
+ int frozen;
+
+ if (argc != 2)
+ error (_("-var-set-format: Usage: NAME FROZEN_FLAG."));
+
+ var = varobj_get_handle (argv[0]);
+ if (var == NULL)
+ error (_("Variable object not found"));
+
+ if (strcmp (argv[1], "0") == 0)
+ frozen = 0;
+ else if (strcmp (argv[1], "1") == 0)
+ frozen = 1;
+ else
+ error (_("Invalid flag value"));
+
+ varobj_set_frozen (var, frozen);
+
+ /* We don't automatically return the new value, or what varobjs got new
+ values during unfreezing. If this information is required, client
+ should call -var-update explicitly. */
+ return MI_CMD_DONE;
+}
+
+
+enum mi_cmd_result
mi_cmd_var_show_format (char *command, char **argv, int argc)
{
enum varobj_display_formats format;
@@ -513,7 +546,7 @@ mi_cmd_var_update (char *command, char *
cr = rootlist;
while (*cr != NULL)
{
- varobj_update_one (*cr, print_values);
+ varobj_update_one (*cr, print_values, 0 /* implicit */);
cr++;
}
do_cleanups (cleanup);
@@ -529,7 +562,7 @@ mi_cmd_var_update (char *command, char *
cleanup = make_cleanup_ui_out_tuple_begin_end (uiout, "changelist");
else
cleanup = make_cleanup_ui_out_list_begin_end (uiout, "changelist");
- varobj_update_one (var, print_values);
+ varobj_update_one (var, print_values, 1 /* explicit */);
do_cleanups (cleanup);
}
return MI_CMD_DONE;
@@ -538,14 +571,15 @@ mi_cmd_var_update (char *command, char *
/* Helper for mi_cmd_var_update(). */
static void
-varobj_update_one (struct varobj *var, enum print_values print_values)
+varobj_update_one (struct varobj *var, enum print_values print_values,
+ int explicit)
{
struct varobj **changelist;
struct varobj **cc;
struct cleanup *cleanup = NULL;
int nc;
- nc = varobj_update (&var, &changelist);
+ nc = varobj_update (&var, &changelist, explicit);
/* nc >= 0 represents the number of changes reported into changelist.
nc < 0 means that an error occured or the the variable has
--- gdb/varobj.c (/mirrors/gdb_mainline) (revision 3769)
+++ gdb/varobj.c (/patches/gdb/frozen2/gdb_mainline) (revision 3769)
@@ -137,6 +137,16 @@ struct varobj
/* Last print value. */
char *print_value;
+
+ /* Is this variable frozen. Frozen variables are never implicitly
+ updated by -var-update *
+ or -var-update <direct-or-indirect-parent>. */
+ int frozen;
+
+ /* Is the value of this variable intentionally not fetched? It is
+ not fetched if either the variable is frozen, or any parents is
+ frozen. */
+ int not_fetched;
};
struct cpstack
@@ -669,6 +679,26 @@ varobj_get_display_format (struct varobj
return var->format;
}
+void
+varobj_set_frozen (struct varobj *var, int frozen)
+{
+ /* When a variable is unfrozen, we don't fetch its value.
+ The 'not_fetched' flag remains set, so next -var-update
+ won't complain.
+
+ We don't fetch the value, because for structures the client
+ should do -var-update anyway. It would be bad to have different
+ client-size logic for structure and other types. */
+ var->frozen = frozen;
+}
+
+int
+varobj_get_frozen (struct varobj *var)
+{
+ return var->frozen;
+}
+
+
int
varobj_get_num_children (struct varobj *var)
{
@@ -915,6 +945,7 @@ install_new_value (struct varobj *var, s
int changeable;
int need_to_fetch;
int changed = 0;
+ int intentionally_not_fetched = 0;
/* We need to know the varobj's type to decide if the value should
be fetched or not. C++ fake children (public/protected/private) don't have
@@ -950,7 +981,20 @@ install_new_value (struct varobj *var, s
will be lazy, which means we've lost that old value. */
if (need_to_fetch && value && value_lazy (value))
{
- if (!gdb_value_fetch_lazy (value))
+ struct varobj *parent = var->parent;
+ int frozen = var->frozen;
+ for (; !frozen && parent; parent = parent->parent)
+ frozen |= parent->frozen;
+
+ 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;
+ }
+ else if (!gdb_value_fetch_lazy (value))
{
/* Set the value to NULL, so that for the next -var-update,
we don't try to compare the new value with this value,
@@ -980,9 +1024,16 @@ install_new_value (struct varobj *var, s
{
/* Try to compare the values. That requires that both
values are non-lazy. */
-
- /* Quick comparison of NULL values. */
- if (var->value == NULL && value == NULL)
+ if (var->not_fetched && value_lazy (var->value))
+ {
+ /* This is a frozen varobj and the value was never read.
+ Presumably, UI shows some "never read" indicator.
+ Now that we've fetched the real value, we need to report
+ this varobj as changed so that UI can show the real
+ value. */
+ changed = 1;
+ }
+ else if (var->value == NULL && value == NULL)
/* Equal. */
;
else if (var->value == NULL || value == NULL)
@@ -1012,9 +1063,13 @@ install_new_value (struct varobj *var, s
}
/* We must always keep the new value, since children depend on it. */
- if (var->value != NULL)
+ if (var->value != NULL && var->value != value)
value_free (var->value);
var->value = value;
+ if (value && value_lazy (value) && intentionally_not_fetched)
+ var->not_fetched = 1;
+ else
+ var->not_fetched = 0;
var->updated = 0;
gdb_assert (!var->value || value_type (var->value));
@@ -1031,17 +1086,21 @@ install_new_value (struct varobj *var, s
< 0 for error values, see varobj.h.
Otherwise it is the number of children + parent changed.
- Only root variables can be updated...
+ The EXPLICIT parameter specifies if this call is result
+ of MI request to update this specific variable, or
+ result of implicit -var-update *. For implicit request, we don't
+ update frozen variables.
NOTE: This function may delete the caller's varobj. If it
returns TYPE_CHANGED, then it has done this and VARP will be modified
to point to the new varobj. */
int
-varobj_update (struct varobj **varp, struct varobj ***changelist)
+varobj_update (struct varobj **varp, struct varobj ***changelist,
+ int explicit)
{
int changed = 0;
- int type_changed;
+ int type_changed = 0;
int i;
int vleft;
struct varobj *v;
@@ -1056,48 +1115,56 @@ varobj_update (struct varobj **varp, str
/* sanity check: have we been passed a pointer? */
gdb_assert (changelist);
- if (!is_root_p (*varp))
- error (_("Only root variables can be updated"));
+ /* Frozen means frozen -- we don't check for any change in
+ this varobj, including its going out of scope, or
+ changing type. One use case for frozen varobjs is
+ retaining previously evaluated expressions, and we don't
+ want them to be reevaluated at all. */
+ if (!explicit && (*varp)->frozen)
+ return 0;
if (!(*varp)->root->is_valid)
return INVALID;
- /* Save the selected stack frame, since we will need to change it
- in order to evaluate expressions. */
- old_fid = get_frame_id (deprecated_safe_get_selected_frame ());
-
- /* Update the root variable. value_of_root can return NULL
- if the variable is no longer around, i.e. we stepped out of
- the frame in which a local existed. We are letting the
- value_of_root variable dispose of the varobj if the type
- has changed. */
- type_changed = 1;
- new = value_of_root (varp, &type_changed);
-
- /* Restore selected frame. */
- fi = frame_find_by_id (old_fid);
- if (fi)
- select_frame (fi);
-
- /* If this is a "use_selected_frame" varobj, and its type has changed,
- them note that it's changed. */
- if (type_changed)
- VEC_safe_push (varobj_p, result, *varp);
-
- if (install_new_value ((*varp), new, type_changed))
+ if ((*varp)->root->rootvar == *varp)
{
- /* If type_changed is 1, install_new_value will never return
- non-zero, so we'll never report the same variable twice. */
- gdb_assert (!type_changed);
- VEC_safe_push (varobj_p, result, *varp);
- }
+ /* Save the selected stack frame, since we will need to change it
+ in order to evaluate expressions. */
+ old_fid = get_frame_id (deprecated_safe_get_selected_frame ());
+
+ /* Update the root variable. value_of_root can return NULL
+ if the variable is no longer around, i.e. we stepped out of
+ the frame in which a local existed. We are letting the
+ value_of_root variable dispose of the varobj if the type
+ has changed. */
+ type_changed = 1;
+ new = value_of_root (varp, &type_changed);
- if (new == NULL)
- {
- /* This means the varobj itself is out of scope.
- Report it. */
- VEC_free (varobj_p, result);
- return NOT_IN_SCOPE;
+ /* Restore selected frame. */
+ fi = frame_find_by_id (old_fid);
+ if (fi)
+ select_frame (fi);
+
+ /* If this is a "use_selected_frame" varobj, and its type has changed,
+ them note that it's changed. */
+ if (type_changed)
+ VEC_safe_push (varobj_p, result, *varp);
+
+ if (install_new_value ((*varp), new, type_changed))
+ {
+ /* If type_changed is 1, install_new_value will never return
+ non-zero, so we'll never report the same variable twice. */
+ gdb_assert (!type_changed);
+ VEC_safe_push (varobj_p, result, *varp);
+ }
+
+ if (new == NULL)
+ {
+ /* This means the varobj itself is out of scope.
+ Report it. */
+ VEC_free (varobj_p, result);
+ return NOT_IN_SCOPE;
+ }
}
VEC_safe_push (varobj_p, stack, *varp);
@@ -1115,13 +1182,13 @@ varobj_update (struct varobj **varp, str
{
varobj_p c = VEC_index (varobj_p, v->children, i);
/* Child may be NULL if explicitly deleted by -var-delete. */
- if (c != NULL)
+ if (c != NULL && !c->frozen)
VEC_safe_push (varobj_p, stack, c);
}
/* Update this variable, unless it's a root, which is already
updated. */
- if (v != *varp)
+ if (v->root->rootvar != v)
{
new = value_of_child (v->parent, v->index);
if (install_new_value (v, new, 0 /* type not changed */))
@@ -1403,6 +1470,8 @@ new_variable (void)
var->root = NULL;
var->updated = 0;
var->print_value = NULL;
+ var->frozen = 0;
+ var->not_fetched = 0;
return var;
}
@@ -2116,6 +2185,12 @@ c_value_of_variable (struct varobj *var)
}
else
{
+ if (var->not_fetched && value_lazy (var->value))
+ /* Frozen variable and no value yet. We don't
+ implicitly fetch the value. MI response will
+ use empty string for the value, which is OK. */
+ return NULL;
+
gdb_assert (varobj_value_is_changeable_p (var));
gdb_assert (!value_lazy (var->value));
return value_get_print_value (var->value, var->format);
--- gdb/varobj.h (/mirrors/gdb_mainline) (revision 3769)
+++ gdb/varobj.h (/patches/gdb/frozen2/gdb_mainline) (revision 3769)
@@ -86,6 +86,10 @@ extern enum varobj_display_formats varob
extern enum varobj_display_formats varobj_get_display_format (
struct varobj *var);
+extern void varobj_set_frozen (struct varobj *var, int frozen);
+
+extern int varobj_get_frozen (struct varobj *var);
+
extern int varobj_get_num_children (struct varobj *var);
extern int varobj_list_children (struct varobj *var,
@@ -105,7 +109,8 @@ extern int varobj_set_value (struct varo
extern int varobj_list (struct varobj ***rootlist);
-extern int varobj_update (struct varobj **varp, struct varobj ***changelist);
+extern int varobj_update (struct varobj **varp, struct varobj ***changelist,
+ int explicit);
extern void varobj_invalidate (void);
[-- Attachment #3: frozen.ChangeLog --]
[-- Type: text/plain, Size: 1312 bytes --]
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-11 14:44 ` Vladimir Prus
@ 2007-04-11 14:52 ` Daniel Jacobowitz
2007-04-11 18:38 ` Eli Zaretskii
2007-04-13 9:53 ` Eli Zaretskii
1 sibling, 1 reply; 33+ messages in thread
From: Daniel Jacobowitz @ 2007-04-11 14:52 UTC (permalink / raw)
To: Vladimir Prus; +Cc: gdb-patches
On Wed, Apr 11, 2007 at 06:43:43PM +0400, Vladimir Prus wrote:
> Wierd, that docs were in previous patch. I've revived them now.
Thanks. Eli, when you have a moment, could you look at this more
complete documentation patch?
Other than that the patch is OK. You might want to double-check
that the ChangeLog entry still matches the patch - I noticed the
mi-support.exp bits were wrong.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-11 14:52 ` Daniel Jacobowitz
@ 2007-04-11 18:38 ` Eli Zaretskii
0 siblings, 0 replies; 33+ messages in thread
From: Eli Zaretskii @ 2007-04-11 18:38 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: vladimir, gdb-patches
> Date: Wed, 11 Apr 2007 10:52:03 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sources.redhat.com
>
> On Wed, Apr 11, 2007 at 06:43:43PM +0400, Vladimir Prus wrote:
> > Wierd, that docs were in previous patch. I've revived them now.
>
> Thanks. Eli, when you have a moment, could you look at this more
> complete documentation patch?
Will do.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-11 14:44 ` Vladimir Prus
2007-04-11 14:52 ` Daniel Jacobowitz
@ 2007-04-13 9:53 ` Eli Zaretskii
2007-04-14 16:14 ` Vladimir Prus
1 sibling, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2007-04-13 9:53 UTC (permalink / raw)
To: Vladimir Prus; +Cc: drow, gdb-patches
> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Wed, 11 Apr 2007 18:43:43 +0400
> Cc: gdb-patches@sources.redhat.com
>
> > 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.
Thanks. I'm okay with the doco patch, after you fix the following
minor problems:
> +leaf variable objects, which always have built-in types. Child variable
^^
Two blanks after a period, please.
> +objects are created only by explicit request, so if a frontend
> +is not interested in children of a particular variable object, no
^^^^^^^^^^^
"in the children"
> +be transferred to the frontend. As noted above, children variable
^^
Two blanks.
> +objects are created on demand, and only leaf variable object have a
^^^^^^^^^^^^^^^^^^^^
"leaf variable objects", in plural.
> +@smallexample
> + -var-set-frozen @var{name} @samp{flag}
> +@end smallexample
> +
> +Set the frozeness flag on the variable object @var{name}. The
> +@samp{flag} parameter should be either @samp{1} to make the variable
> +frozen or @samp{0} to make it unfozen.
Here `flag' stands for something else (0 or 1), so it should be in
@var, not @samp, like `name'.
> If a variable object is
> +frozen, then neither itself, nor any of its children, are
> +implicitly updated by @code{-var-update} of a parent variable or
> +by @code{-var-update *}.
A @pxref here to where -var-update is described would be a good idea.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-13 9:53 ` Eli Zaretskii
@ 2007-04-14 16:14 ` Vladimir Prus
2007-04-14 16:19 ` Daniel Jacobowitz
` (3 more replies)
0 siblings, 4 replies; 33+ messages in thread
From: Vladimir Prus @ 2007-04-14 16:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: drow, gdb-patches
[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]
On Friday 13 April 2007 13:53, Eli Zaretskii wrote:
> > From: Vladimir Prus <vladimir@codesourcery.com>
> > Date: Wed, 11 Apr 2007 18:43:43 +0400
> > Cc: gdb-patches@sources.redhat.com
> >
> > > 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.
>
> Thanks. I'm okay with the doco patch, after you fix the following
> minor problems:
....
> > If a variable object is
> > +frozen, then neither itself, nor any of its children, are
> > +implicitly updated by @code{-var-update} of a parent variable or
> > +by @code{-var-update *}.
>
> A @pxref here to where -var-update is described would be a good idea.
Here's what I've just checked in. There was already -var-update anchor, but
it was on the list of varobj attributes, so I've renamed it, and added -var-update
anchor at the top of -var-update description.
- Volodya
[-- Attachment #2: frozen2__gdb_mainline.diff --]
[-- Type: text/x-diff, Size: 23484 bytes --]
--- gdb/doc/gdb.texinfo (/mirrors/gdb_mainline) (revision 3778)
+++ gdb/doc/gdb.texinfo (/patches/gdb/frozen2/gdb_mainline) (revision 3778)
@@ -17609,7 +17609,7 @@ New fields may be added to the output of
@item
The range of values for fields with specified values, e.g.,
-@code{in_scope} (@pxref{-var-update}) may be extended.
+@code{in_scope} (@pxref{-var-update-fields}) may be extended.
@c The format of field's content e.g type prefix, may change so parse it
@c at your own risk. Yes, in general?
@@ -19536,7 +19536,10 @@ that corresponds to a composite type, su
a number of child variable objects, for example corresponding to each
element of a structure. A child variable object can itself have
children, recursively. Recursion ends when we reach
-leaf variable objects, which always have built-in types.
+leaf variable objects, which always have built-in types. Child variable
+objects are created only by explicit request, so if a frontend
+is not interested in the children of a particular variable object, no
+child will be created.
For a leaf variable object it is possible to obtain its value as a
string, or set the value from a string. String value can be also
@@ -19548,7 +19551,19 @@ A frontend does not need to read the val
the program stops. Instead, MI provides an update command that lists all
variable objects whose values has changed since the last update
operation. This considerably reduces the amount of data that must
-be transferred to the frontend.
+be transferred to the frontend. As noted above, children variable
+objects are created on demand, and only leaf variable objects have a
+real value. As result, gdb will read target memory only for leaf
+variables that frontend has created.
+
+The automatic update is not always desirable. For example, a frontend
+might want to keep a value of some expression for future reference,
+and never update it. For another example, fetching memory is
+relatively slow for embedded targets, so a frontend might want
+to disable automatic update for the variables that are either not
+visible on the screen, or ``closed''. This is possible using so
+called ``frozen variable objects''. Such variable objects are never
+implicitly updated.
The following is the complete set of @sc{gdb/mi} operations defined to
access this functionality:
@@ -19581,6 +19596,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
@@ -19846,6 +19863,7 @@ subsequent @code{-var-update} list.
@subheading The @code{-var-update} Command
@findex -var-update
+@anchor{-var-update}
@subsubheading Synopsis
@@ -19880,7 +19898,7 @@ type_changed="false"@}]
(gdb)
@end smallexample
-@anchor{-var-update}
+@anchor{-var-update-fields}
The field in_scope may take three values:
@table @code
@@ -19903,6 +19921,37 @@ objects.
In the future new values may be added to this list so the front should
be prepared for this possibility. @xref{GDB/MI Development and Front Ends, ,@sc{GDB/MI} Development and Front Ends}.
+@subheading The @code{-var-set-frozen} Command
+@findex -var-set-frozen
+
+@subsubheading Synopsis
+
+@smallexample
+ -var-set-frozen @var{name} @samp{flag}
+@end smallexample
+
+Set the frozeness flag on the variable object @var{name}. The
+@var{flag} parameter should be either @samp{1} to make the variable
+frozen or @samp{0} to make it unfozen. If a variable object is
+frozen, then neither itself, nor any of its children, are
+implicitly updated by @code{-var-update} (@pxref{-var-update}) of
+a parent variable or by @code{-var-update *}. Only
+@code{-var-update} of the variable itself will update its value and
+values of its children. After a variable object is unfrozen, it is
+implicitly updated by all subsequent @code{-var-update} operations.
+Unfreezing a variable does not update it, only subsequent
+@code{-var-update} does.
+
+@subsubheading Example
+
+@smallexample
+(gdb)
+-var-set-frozen V 1
+^done
+(gdb)
+@end smallexample
+
+
@c %%%%%%%%%%%%%%%%%%%%%%%%%%%% SECTION %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@node GDB/MI Data Manipulation
@section @sc{gdb/mi} Data Manipulation
--- gdb/testsuite/gdb.mi/mi-var-cmd.exp (/mirrors/gdb_mainline) (revision 3778)
+++ gdb/testsuite/gdb.mi/mi-var-cmd.exp (/patches/gdb/frozen2/gdb_mainline) (revision 3778)
@@ -596,6 +596,20 @@ mi_gdb_test "-var-update selected_a" \
"\\^done,changelist=\\\[\{name=\"selected_a\",in_scope=\"true\",new_type=\"int\",new_num_children=\"0\"\}\\\]" \
"update selected_a in do_special_tests"
+mi_delete_varobj selected_a "delete selected_a"
+mi_delete_varobj array_ptr "delete array_ptr"
+
+proc set_frozen {varobjs flag} {
+ foreach v $varobjs {
+ mi_gdb_test "-var-set-frozen $v $flag" \
+ "\\^done" \
+ "-var-set-frozen $v $flag"
+ }
+}
+
+mi_prepare_inline_tests $srcfile
+mi_run_inline_test frozen
+
# Test whether bad varobjs crash GDB.
# A varobj we fail to read during -var-update should be considered
--- gdb/testsuite/gdb.mi/var-cmd.c (/mirrors/gdb_mainline) (revision 3778)
+++ gdb/testsuite/gdb.mi/var-cmd.c (/patches/gdb/frozen2/gdb_mainline) (revision 3778)
@@ -315,6 +315,92 @@ do_special_tests (void)
incr_a(2);
}
+void do_frozen_tests ()
+{
+ /*: BEGIN: frozen :*/
+ struct {
+ int i;
+ struct {
+ int j;
+ int k;
+ } nested;
+ } v1 = {1, {2, 3}};
+
+ int v2 = 4;
+ /*:
+ mi_create_varobj V1 v1 "create varobj for v1"
+ mi_create_varobj V2 v2 "create varobj for v2"
+
+ mi_list_varobj_children "V1" {
+ {"V1.i" "i" "0" "int"}
+ {"V1.nested" "nested" "2" "struct {...}"}
+ } "list children of v1"
+
+ mi_list_varobj_children "V1.nested" {
+ {"V1.nested.j" "j" "0" "int"}
+ {"V1.nested.k" "k" "0" "int"}
+ } "list children of v1.nested"
+
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 2 "check V1.nested.j: 2"
+ mi_check_varobj_value V1.nested.k 3 "check V1.nested.k: 3"
+ mi_check_varobj_value V2 4 "check V2: 4"
+ :*/
+ v2 = 5;
+ /*:
+ mi_varobj_update * {V2} "update varobjs: V2 changed"
+ set_frozen V2 1
+ :*/
+ v2 = 6;
+ /*:
+ mi_varobj_update * {} "update varobjs: nothing changed"
+ mi_check_varobj_value V2 5 "check V2: 5"
+ mi_varobj_update V2 {V2} "update V2 explicitly"
+ mi_check_varobj_value V2 6 "check V2: 6"
+ :*/
+ v1.i = 7;
+ v1.nested.j = 8;
+ v1.nested.k = 9;
+ /*:
+ set_frozen V1 1
+ mi_varobj_update * {} "update varobjs: nothing changed"
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 2 "check V1.nested.j: 2"
+ mi_check_varobj_value V1.nested.k 3 "check V1.nested.k: 3"
+ # Check that explicit update for elements of structures
+ # works.
+ # Update v1.j
+ mi_varobj_update V1.nested.j {V1.nested.j} "update V1.nested.j"
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 8 "check V1.nested.j: 8"
+ mi_check_varobj_value V1.nested.k 3 "check V1.nested.k: 3"
+ # Update v1.nested, check that children is updated.
+ mi_varobj_update V1.nested {V1.nested.k} "update V1.nested"
+ mi_check_varobj_value V1.i 1 "check V1.i: 1"
+ mi_check_varobj_value V1.nested.j 8 "check V1.nested.j: 8"
+ mi_check_varobj_value V1.nested.k 9 "check V1.nested.k: 9"
+ # Update v1.i
+ mi_varobj_update V1.i {V1.i} "update V1.i"
+ mi_check_varobj_value V1.i 7 "check V1.i: 7"
+ :*/
+ v1.i = 10;
+ v1.nested.j = 11;
+ v1.nested.k = 12;
+ /*:
+ # Check that unfreeze itself does not updates the values.
+ set_frozen V1 0
+ mi_check_varobj_value V1.i 7 "check V1.i: 7"
+ mi_check_varobj_value V1.nested.j 8 "check V1.nested.j: 8"
+ mi_check_varobj_value V1.nested.k 9 "check V1.nested.k: 9"
+ mi_varobj_update V1 {V1.i V1.nested.j V1.nested.k} "update V1"
+ mi_check_varobj_value V1.i 10 "check V1.i: 10"
+ mi_check_varobj_value V1.nested.j 11 "check V1.nested.j: 11"
+ mi_check_varobj_value V1.nested.k 12 "check V1.nested.k: 12"
+ :*/
+
+ /*: END: frozen :*/
+}
+
int
main (int argc, char *argv [])
{
@@ -322,6 +408,7 @@ main (int argc, char *argv [])
do_block_tests ();
do_children_tests ();
do_special_tests ();
+ do_frozen_tests ();
exit (0);
}
--- gdb/testsuite/lib/mi-support.exp (/mirrors/gdb_mainline) (revision 3778)
+++ gdb/testsuite/lib/mi-support.exp (/patches/gdb/frozen2/gdb_mainline) (revision 3778)
@@ -1024,8 +1024,9 @@ proc mi_varobj_update { name expected te
set first 1
foreach item $expected {
set v "{name=\"$item\",in_scope=\"true\",type_changed=\"false\"}"
- if {$first} {
+ if {$first == 1} {
set er "$er$v"
+ set first 0
} else {
set er "$er,$v"
}
@@ -1312,7 +1313,7 @@ proc mi_run_inline_test { testcase } {
set line_now [mi_wait_for_stop "$testcase: step to $line"]
set first 0
} elseif {$line_now!=$line} {
- set line_now [mi_continue_to_line "$mi_autotest_source:$line"]
+ set line_now [mi_continue_to_line "$mi_autotest_source:$line" "continue to $line"]
}
if {$line_now!=$line} {
--- gdb/mi/mi-cmds.h (/mirrors/gdb_mainline) (revision 3778)
+++ gdb/mi/mi-cmds.h (/patches/gdb/frozen2/gdb_mainline) (revision 3778)
@@ -113,6 +113,7 @@ extern mi_cmd_argv_ftype mi_cmd_var_info
extern mi_cmd_argv_ftype mi_cmd_var_info_type;
extern mi_cmd_argv_ftype mi_cmd_var_list_children;
extern mi_cmd_argv_ftype mi_cmd_var_set_format;
+extern mi_cmd_argv_ftype mi_cmd_var_set_frozen;
extern mi_cmd_argv_ftype mi_cmd_var_show_attributes;
extern mi_cmd_argv_ftype mi_cmd_var_show_format;
extern mi_cmd_argv_ftype mi_cmd_var_update;
--- gdb/mi/mi-cmds.c (/mirrors/gdb_mainline) (revision 3778)
+++ gdb/mi/mi-cmds.c (/patches/gdb/frozen2/gdb_mainline) (revision 3778)
@@ -156,6 +156,7 @@ struct mi_cmd mi_cmds[] =
{ "var-info-type", { NULL, 0 }, 0, mi_cmd_var_info_type},
{ "var-list-children", { NULL, 0 }, 0, mi_cmd_var_list_children},
{ "var-set-format", { NULL, 0 }, 0, mi_cmd_var_set_format},
+ { "var-set-frozen", { NULL, 0 }, 0, mi_cmd_var_set_frozen},
{ "var-show-attributes", { NULL, 0 }, 0, mi_cmd_var_show_attributes},
{ "var-show-format", { NULL, 0 }, 0, mi_cmd_var_show_format},
{ "var-update", { NULL, 0 }, 0, mi_cmd_var_update},
--- gdb/mi/mi-cmd-var.c (/mirrors/gdb_mainline) (revision 3778)
+++ gdb/mi/mi-cmd-var.c (/patches/gdb/frozen2/gdb_mainline) (revision 3778)
@@ -37,7 +37,8 @@ const char mi_all_values[] = "--all-valu
extern int varobjdebug; /* defined in varobj.c. */
static void varobj_update_one (struct varobj *var,
- enum print_values print_values);
+ enum print_values print_values,
+ int explicit);
static int mi_print_value_p (struct type *type, enum print_values print_values);
@@ -64,6 +65,9 @@ print_varobj (struct varobj *var, enum p
ui_out_field_string (uiout, "type", type);
xfree (type);
}
+
+ if (varobj_get_frozen (var))
+ ui_out_field_int (uiout, "frozen", 1);
}
/* VAROBJ operations */
@@ -233,6 +237,35 @@ mi_cmd_var_set_format (char *command, ch
}
enum mi_cmd_result
+mi_cmd_var_set_frozen (char *command, char **argv, int argc)
+{
+ struct varobj *var;
+ int frozen;
+
+ if (argc != 2)
+ error (_("-var-set-format: Usage: NAME FROZEN_FLAG."));
+
+ var = varobj_get_handle (argv[0]);
+ if (var == NULL)
+ error (_("Variable object not found"));
+
+ if (strcmp (argv[1], "0") == 0)
+ frozen = 0;
+ else if (strcmp (argv[1], "1") == 0)
+ frozen = 1;
+ else
+ error (_("Invalid flag value"));
+
+ varobj_set_frozen (var, frozen);
+
+ /* We don't automatically return the new value, or what varobjs got new
+ values during unfreezing. If this information is required, client
+ should call -var-update explicitly. */
+ return MI_CMD_DONE;
+}
+
+
+enum mi_cmd_result
mi_cmd_var_show_format (char *command, char **argv, int argc)
{
enum varobj_display_formats format;
@@ -513,7 +546,7 @@ mi_cmd_var_update (char *command, char *
cr = rootlist;
while (*cr != NULL)
{
- varobj_update_one (*cr, print_values);
+ varobj_update_one (*cr, print_values, 0 /* implicit */);
cr++;
}
do_cleanups (cleanup);
@@ -529,7 +562,7 @@ mi_cmd_var_update (char *command, char *
cleanup = make_cleanup_ui_out_tuple_begin_end (uiout, "changelist");
else
cleanup = make_cleanup_ui_out_list_begin_end (uiout, "changelist");
- varobj_update_one (var, print_values);
+ varobj_update_one (var, print_values, 1 /* explicit */);
do_cleanups (cleanup);
}
return MI_CMD_DONE;
@@ -538,14 +571,15 @@ mi_cmd_var_update (char *command, char *
/* Helper for mi_cmd_var_update(). */
static void
-varobj_update_one (struct varobj *var, enum print_values print_values)
+varobj_update_one (struct varobj *var, enum print_values print_values,
+ int explicit)
{
struct varobj **changelist;
struct varobj **cc;
struct cleanup *cleanup = NULL;
int nc;
- nc = varobj_update (&var, &changelist);
+ nc = varobj_update (&var, &changelist, explicit);
/* nc >= 0 represents the number of changes reported into changelist.
nc < 0 means that an error occured or the the variable has
--- gdb/varobj.c (/mirrors/gdb_mainline) (revision 3778)
+++ gdb/varobj.c (/patches/gdb/frozen2/gdb_mainline) (revision 3778)
@@ -137,6 +137,16 @@ struct varobj
/* Last print value. */
char *print_value;
+
+ /* Is this variable frozen. Frozen variables are never implicitly
+ updated by -var-update *
+ or -var-update <direct-or-indirect-parent>. */
+ int frozen;
+
+ /* Is the value of this variable intentionally not fetched? It is
+ not fetched if either the variable is frozen, or any parents is
+ frozen. */
+ int not_fetched;
};
struct cpstack
@@ -669,6 +679,26 @@ varobj_get_display_format (struct varobj
return var->format;
}
+void
+varobj_set_frozen (struct varobj *var, int frozen)
+{
+ /* When a variable is unfrozen, we don't fetch its value.
+ The 'not_fetched' flag remains set, so next -var-update
+ won't complain.
+
+ We don't fetch the value, because for structures the client
+ should do -var-update anyway. It would be bad to have different
+ client-size logic for structure and other types. */
+ var->frozen = frozen;
+}
+
+int
+varobj_get_frozen (struct varobj *var)
+{
+ return var->frozen;
+}
+
+
int
varobj_get_num_children (struct varobj *var)
{
@@ -915,6 +945,7 @@ install_new_value (struct varobj *var, s
int changeable;
int need_to_fetch;
int changed = 0;
+ int intentionally_not_fetched = 0;
/* We need to know the varobj's type to decide if the value should
be fetched or not. C++ fake children (public/protected/private) don't have
@@ -950,7 +981,20 @@ install_new_value (struct varobj *var, s
will be lazy, which means we've lost that old value. */
if (need_to_fetch && value && value_lazy (value))
{
- if (!gdb_value_fetch_lazy (value))
+ struct varobj *parent = var->parent;
+ int frozen = var->frozen;
+ for (; !frozen && parent; parent = parent->parent)
+ frozen |= parent->frozen;
+
+ 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;
+ }
+ else if (!gdb_value_fetch_lazy (value))
{
/* Set the value to NULL, so that for the next -var-update,
we don't try to compare the new value with this value,
@@ -980,9 +1024,16 @@ install_new_value (struct varobj *var, s
{
/* Try to compare the values. That requires that both
values are non-lazy. */
-
- /* Quick comparison of NULL values. */
- if (var->value == NULL && value == NULL)
+ if (var->not_fetched && value_lazy (var->value))
+ {
+ /* This is a frozen varobj and the value was never read.
+ Presumably, UI shows some "never read" indicator.
+ Now that we've fetched the real value, we need to report
+ this varobj as changed so that UI can show the real
+ value. */
+ changed = 1;
+ }
+ else if (var->value == NULL && value == NULL)
/* Equal. */
;
else if (var->value == NULL || value == NULL)
@@ -1012,9 +1063,13 @@ install_new_value (struct varobj *var, s
}
/* We must always keep the new value, since children depend on it. */
- if (var->value != NULL)
+ if (var->value != NULL && var->value != value)
value_free (var->value);
var->value = value;
+ if (value && value_lazy (value) && intentionally_not_fetched)
+ var->not_fetched = 1;
+ else
+ var->not_fetched = 0;
var->updated = 0;
gdb_assert (!var->value || value_type (var->value));
@@ -1031,17 +1086,21 @@ install_new_value (struct varobj *var, s
< 0 for error values, see varobj.h.
Otherwise it is the number of children + parent changed.
- Only root variables can be updated...
+ The EXPLICIT parameter specifies if this call is result
+ of MI request to update this specific variable, or
+ result of implicit -var-update *. For implicit request, we don't
+ update frozen variables.
NOTE: This function may delete the caller's varobj. If it
returns TYPE_CHANGED, then it has done this and VARP will be modified
to point to the new varobj. */
int
-varobj_update (struct varobj **varp, struct varobj ***changelist)
+varobj_update (struct varobj **varp, struct varobj ***changelist,
+ int explicit)
{
int changed = 0;
- int type_changed;
+ int type_changed = 0;
int i;
int vleft;
struct varobj *v;
@@ -1056,48 +1115,56 @@ varobj_update (struct varobj **varp, str
/* sanity check: have we been passed a pointer? */
gdb_assert (changelist);
- if (!is_root_p (*varp))
- error (_("Only root variables can be updated"));
+ /* Frozen means frozen -- we don't check for any change in
+ this varobj, including its going out of scope, or
+ changing type. One use case for frozen varobjs is
+ retaining previously evaluated expressions, and we don't
+ want them to be reevaluated at all. */
+ if (!explicit && (*varp)->frozen)
+ return 0;
if (!(*varp)->root->is_valid)
return INVALID;
- /* Save the selected stack frame, since we will need to change it
- in order to evaluate expressions. */
- old_fid = get_frame_id (deprecated_safe_get_selected_frame ());
-
- /* Update the root variable. value_of_root can return NULL
- if the variable is no longer around, i.e. we stepped out of
- the frame in which a local existed. We are letting the
- value_of_root variable dispose of the varobj if the type
- has changed. */
- type_changed = 1;
- new = value_of_root (varp, &type_changed);
-
- /* Restore selected frame. */
- fi = frame_find_by_id (old_fid);
- if (fi)
- select_frame (fi);
-
- /* If this is a "use_selected_frame" varobj, and its type has changed,
- them note that it's changed. */
- if (type_changed)
- VEC_safe_push (varobj_p, result, *varp);
-
- if (install_new_value ((*varp), new, type_changed))
+ if ((*varp)->root->rootvar == *varp)
{
- /* If type_changed is 1, install_new_value will never return
- non-zero, so we'll never report the same variable twice. */
- gdb_assert (!type_changed);
- VEC_safe_push (varobj_p, result, *varp);
- }
+ /* Save the selected stack frame, since we will need to change it
+ in order to evaluate expressions. */
+ old_fid = get_frame_id (deprecated_safe_get_selected_frame ());
+
+ /* Update the root variable. value_of_root can return NULL
+ if the variable is no longer around, i.e. we stepped out of
+ the frame in which a local existed. We are letting the
+ value_of_root variable dispose of the varobj if the type
+ has changed. */
+ type_changed = 1;
+ new = value_of_root (varp, &type_changed);
- if (new == NULL)
- {
- /* This means the varobj itself is out of scope.
- Report it. */
- VEC_free (varobj_p, result);
- return NOT_IN_SCOPE;
+ /* Restore selected frame. */
+ fi = frame_find_by_id (old_fid);
+ if (fi)
+ select_frame (fi);
+
+ /* If this is a "use_selected_frame" varobj, and its type has changed,
+ them note that it's changed. */
+ if (type_changed)
+ VEC_safe_push (varobj_p, result, *varp);
+
+ if (install_new_value ((*varp), new, type_changed))
+ {
+ /* If type_changed is 1, install_new_value will never return
+ non-zero, so we'll never report the same variable twice. */
+ gdb_assert (!type_changed);
+ VEC_safe_push (varobj_p, result, *varp);
+ }
+
+ if (new == NULL)
+ {
+ /* This means the varobj itself is out of scope.
+ Report it. */
+ VEC_free (varobj_p, result);
+ return NOT_IN_SCOPE;
+ }
}
VEC_safe_push (varobj_p, stack, *varp);
@@ -1115,13 +1182,13 @@ varobj_update (struct varobj **varp, str
{
varobj_p c = VEC_index (varobj_p, v->children, i);
/* Child may be NULL if explicitly deleted by -var-delete. */
- if (c != NULL)
+ if (c != NULL && !c->frozen)
VEC_safe_push (varobj_p, stack, c);
}
/* Update this variable, unless it's a root, which is already
updated. */
- if (v != *varp)
+ if (v->root->rootvar != v)
{
new = value_of_child (v->parent, v->index);
if (install_new_value (v, new, 0 /* type not changed */))
@@ -1403,6 +1470,8 @@ new_variable (void)
var->root = NULL;
var->updated = 0;
var->print_value = NULL;
+ var->frozen = 0;
+ var->not_fetched = 0;
return var;
}
@@ -2116,6 +2185,12 @@ c_value_of_variable (struct varobj *var)
}
else
{
+ if (var->not_fetched && value_lazy (var->value))
+ /* Frozen variable and no value yet. We don't
+ implicitly fetch the value. MI response will
+ use empty string for the value, which is OK. */
+ return NULL;
+
gdb_assert (varobj_value_is_changeable_p (var));
gdb_assert (!value_lazy (var->value));
return value_get_print_value (var->value, var->format);
--- gdb/varobj.h (/mirrors/gdb_mainline) (revision 3778)
+++ gdb/varobj.h (/patches/gdb/frozen2/gdb_mainline) (revision 3778)
@@ -86,6 +86,10 @@ extern enum varobj_display_formats varob
extern enum varobj_display_formats varobj_get_display_format (
struct varobj *var);
+extern void varobj_set_frozen (struct varobj *var, int frozen);
+
+extern int varobj_get_frozen (struct varobj *var);
+
extern int varobj_get_num_children (struct varobj *var);
extern int varobj_list_children (struct varobj *var,
@@ -105,7 +109,8 @@ extern int varobj_set_value (struct varo
extern int varobj_list (struct varobj ***rootlist);
-extern int varobj_update (struct varobj **varp, struct varobj ***changelist);
+extern int varobj_update (struct varobj **varp, struct varobj ***changelist,
+ int explicit);
extern void varobj_invalidate (void);
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-14 16:14 ` Vladimir Prus
@ 2007-04-14 16:19 ` Daniel Jacobowitz
2007-04-14 23:18 ` Nick Roberts
2007-04-14 20:32 ` Eli Zaretskii
` (2 subsequent siblings)
3 siblings, 1 reply; 33+ messages in thread
From: Daniel Jacobowitz @ 2007-04-14 16:19 UTC (permalink / raw)
To: Vladimir Prus; +Cc: Eli Zaretskii, gdb-patches
On Sat, Apr 14, 2007 at 01:53:51PM +0400, Vladimir Prus wrote:
> @item
> The range of values for fields with specified values, e.g.,
> -@code{in_scope} (@pxref{-var-update}) may be extended.
> +@code{in_scope} (@pxref{-var-update-fields}) may be extended.
Doesn't that read a little odd to you? I'd think '-var-update fields'
at least.
Thanks!
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-14 16:14 ` Vladimir Prus
2007-04-14 16:19 ` Daniel Jacobowitz
@ 2007-04-14 20:32 ` Eli Zaretskii
2007-04-15 11:42 ` Vladimir Prus
2007-04-15 8:04 ` Nick Roberts
2007-04-18 10:22 ` [patch] fix insight (was: Re: Ping: frozen variable objects) Brian Dessent
3 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2007-04-14 20:32 UTC (permalink / raw)
To: Vladimir Prus; +Cc: drow, gdb-patches
> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Sat, 14 Apr 2007 13:53:51 +0400
> Cc: drow@false.org, gdb-patches@sources.redhat.com
>
> Here's what I've just checked in. There was already -var-update anchor, but
> it was on the list of varobj attributes, so I've renamed it, and added -var-update
> anchor at the top of -var-update description.
Thanks.
> +@smallexample
> + -var-set-frozen @var{name} @samp{flag}
> +@end smallexample
> +
> +Set the frozeness flag on the variable object @var{name}. The
> +@var{flag} parameter should be either @samp{1} to make the variable
``flag'' should be in @var in the example as well, not only in the
text.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-14 16:19 ` Daniel Jacobowitz
@ 2007-04-14 23:18 ` Nick Roberts
2007-04-15 10:32 ` Vladimir Prus
2007-04-15 10:35 ` Vladimir Prus
0 siblings, 2 replies; 33+ messages in thread
From: Nick Roberts @ 2007-04-14 23:18 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Vladimir Prus, Eli Zaretskii, gdb-patches
> > The range of values for fields with specified values, e.g.,
> > -@code{in_scope} (@pxref{-var-update}) may be extended.
> > +@code{in_scope} (@pxref{-var-update-fields}) may be extended.
>
> Doesn't that read a little odd to you? I'd think '-var-update fields'
> at least.
Also the name that is displayed shouldn't change, so pxref needs to be
called with two arguments:
@code{in_scope} (@pxref{-var-update fields, -var-update}) may be extended.
and
@anchor{-var-update fields}
The field in_scope may take three values:
Here are some other observations about the documentation:
frozenness (not a common word) has two ns.
In the description for -var-set-frozen:
parameter should be either `1' to make the variable frozen or `0' to
make it unfozen. If a variable object is frozen, then neither itself,
^^^^^^^
In the description for -var-update:
If `*' is used as the variable object names, all existing variable objects
are updated.
Since frozen variables aren't updated implicitly, I would move some
of the description of them from -var-set-frozen to here.
@c The format of field's content e.g type prefix, may change so parse it
@c at your own risk. Yes, in general?
@@ -19536,7 +19536,10 @@ that corresponds to a composite type, su
a number of child variable objects, for example corresponding to each
element of a structure. A child variable object can itself have
children, recursively. Recursion ends when we reach
-leaf variable objects, which always have built-in types.
+leaf variable objects, which always have built-in types. Child variable
+objects are created only by explicit request, so if a frontend
+is not interested in the children of a particular variable object, no
+child will be created.
For a leaf variable object it is possible to obtain its value as a
string, or set the value from a string. String value can be also
@@ -19548,7 +19551,19 @@ A frontend does not need to read the val
the program stops. Instead, MI provides an update command that lists all
variable objects whose values has changed since the last update
operation. This considerably reduces the amount of data that must
-be transferred to the frontend.
+be transferred to the frontend. As noted above, children variable
+objects are created on demand, and only leaf variable objects have a
+real value. As result, gdb will read target memory only for leaf
+variables that frontend has created.
Why not just:
@c The format of field's content e.g type prefix, may change so parse it
@c at your own risk. Yes, in general?
@@ -19536,7 +19536,10 @@ that corresponds to a composite type, su
a number of child variable objects, for example corresponding to each
element of a structure. A child variable object can itself have
children, recursively. Recursion ends when we reach
-leaf variable objects, which always have built-in types.
+leaf variable objects, which always have built-in types. Child variable
+objects are created only by explicit request, so if a frontend
+is not interested in the children of a particular variable object, no
+child will be created. As result, gdb will read target memory only for
+leaf variables that frontend has created.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-14 16:14 ` Vladimir Prus
2007-04-14 16:19 ` Daniel Jacobowitz
2007-04-14 20:32 ` Eli Zaretskii
@ 2007-04-15 8:04 ` Nick Roberts
2007-04-18 10:22 ` [patch] fix insight (was: Re: Ping: frozen variable objects) Brian Dessent
3 siblings, 0 replies; 33+ messages in thread
From: Nick Roberts @ 2007-04-15 8:04 UTC (permalink / raw)
To: Vladimir Prus; +Cc: Eli Zaretskii, drow, gdb-patches
> + if (varobj_get_frozen (var))
> + ui_out_field_int (uiout, "frozen", 1);
So the frozen value is implicitly 0 if the field is not printed? More
importantly, I don't see how the front end can find out if a simple variable
object (not a child) is frozen or not. You could say that the front end
should keep track of this, but this would also be an argument against having
a frozen field at all.
--
Nick http://www.inet.net.nz/~nickrob
int m[10];
(gdb)
-var-create - * m
^done,name="var1",numchild="10",value="[10]",type="int [10]"
(gdb)
-var-set-frozen var1 1
How can I see that var1 is frozen?
Another (related) doc thought:
`-var-set-frozen' set frozeness attribute
This suggests that -var-show-attributes will display frozenness.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-14 23:18 ` Nick Roberts
@ 2007-04-15 10:32 ` Vladimir Prus
2007-04-15 10:35 ` Vladimir Prus
1 sibling, 0 replies; 33+ messages in thread
From: Vladimir Prus @ 2007-04-15 10:32 UTC (permalink / raw)
To: Nick Roberts; +Cc: Daniel Jacobowitz, Eli Zaretskii, gdb-patches
On Sunday 15 April 2007 02:53, Nick Roberts wrote:
> > > The range of values for fields with specified values, e.g.,
> > > -@code{in_scope} (@pxref{-var-update}) may be extended.
> > > +@code{in_scope} (@pxref{-var-update-fields}) may be extended.
> >
> > Doesn't that read a little odd to you? I'd think '-var-update fields'
> > at least.
>
> Also the name that is displayed shouldn't change, so pxref needs to be
> called with two arguments:
>
>
> @code{in_scope} (@pxref{-var-update fields, -var-update}) may be extended.
>
> and
>
> @anchor{-var-update fields}
> The field in_scope may take three values:
>
> Here are some other observations about the documentation:
>
> frozenness (not a common word) has two ns.
>
> In the description for -var-set-frozen:
>
> parameter should be either `1' to make the variable frozen or `0' to
> make it unfozen. If a variable object is frozen, then neither itself,
> ^^^^^^^
>
> In the description for -var-update:
>
> If `*' is used as the variable object names, all existing variable objects
> are updated.
>
> Since frozen variables aren't updated implicitly, I would move some
> of the description of them from -var-set-frozen to here.
I think cross-reference will be fine.
> @c The format of field's content e.g type prefix, may change so parse it
> @c at your own risk. Yes, in general?
> @@ -19536,7 +19536,10 @@ that corresponds to a composite type, su
> a number of child variable objects, for example corresponding to each
> element of a structure. A child variable object can itself have
> children, recursively. Recursion ends when we reach
> -leaf variable objects, which always have built-in types.
> +leaf variable objects, which always have built-in types. Child variable
> +objects are created only by explicit request, so if a frontend
> +is not interested in the children of a particular variable object, no
> +child will be created.
>
> For a leaf variable object it is possible to obtain its value as a
> string, or set the value from a string. String value can be also
> @@ -19548,7 +19551,19 @@ A frontend does not need to read the val
> the program stops. Instead, MI provides an update command that lists all
> variable objects whose values has changed since the last update
> operation. This considerably reduces the amount of data that must
> -be transferred to the frontend.
> +be transferred to the frontend. As noted above, children variable
> +objects are created on demand, and only leaf variable objects have a
> +real value. As result, gdb will read target memory only for leaf
> +variables that frontend has created.
>
> Why not just:
>
> @c The format of field's content e.g type prefix, may change so parse it
> @c at your own risk. Yes, in general?
> @@ -19536,7 +19536,10 @@ that corresponds to a composite type, su
> a number of child variable objects, for example corresponding to each
> element of a structure. A child variable object can itself have
> children, recursively. Recursion ends when we reach
> -leaf variable objects, which always have built-in types.
> +leaf variable objects, which always have built-in types. Child variable
> +objects are created only by explicit request, so if a frontend
> +is not interested in the children of a particular variable object, no
> +child will be created. As result, gdb will read target memory only for
> +leaf variables that frontend has created.
Because I wanted to say that -var-update specifically does not read memory
for entire structures.
- Volodya
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-14 23:18 ` Nick Roberts
2007-04-15 10:32 ` Vladimir Prus
@ 2007-04-15 10:35 ` Vladimir Prus
2007-04-15 11:46 ` Nick Roberts
2007-04-15 20:13 ` Eli Zaretskii
1 sibling, 2 replies; 33+ messages in thread
From: Vladimir Prus @ 2007-04-15 10:35 UTC (permalink / raw)
To: Nick Roberts; +Cc: Daniel Jacobowitz, Eli Zaretskii, gdb-patches
On Sunday 15 April 2007 02:53, Nick Roberts wrote:
> > > The range of values for fields with specified values, e.g.,
> > > -@code{in_scope} (@pxref{-var-update}) may be extended.
> > > +@code{in_scope} (@pxref{-var-update-fields}) may be extended.
> >
> > Doesn't that read a little odd to you? I'd think '-var-update fields'
> > at least.
>
> Also the name that is displayed shouldn't change, so pxref needs to be
> called with two arguments:
>
>
> @code{in_scope} (@pxref{-var-update fields, -var-update}) may be extended.
That does not seem to work in a sensible way. In PDF, you get "-var-update fields"
only, and info has:
(*note -var-update: -var-update fields.)
which makes no sense whatsoever.
- Volodya
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-14 20:32 ` Eli Zaretskii
@ 2007-04-15 11:42 ` Vladimir Prus
2007-04-15 12:03 ` Nick Roberts
2007-04-15 20:14 ` Eli Zaretskii
0 siblings, 2 replies; 33+ messages in thread
From: Vladimir Prus @ 2007-04-15 11:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: drow, gdb-patches
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
On Saturday 14 April 2007 22:50, Eli Zaretskii wrote:
> > From: Vladimir Prus <vladimir@codesourcery.com>
> > Date: Sat, 14 Apr 2007 13:53:51 +0400
> > Cc: drow@false.org, gdb-patches@sources.redhat.com
> >
> > Here's what I've just checked in. There was already -var-update anchor, but
> > it was on the list of varobj attributes, so I've renamed it, and added -var-update
> > anchor at the top of -var-update description.
>
> Thanks.
>
> > +@smallexample
> > + -var-set-frozen @var{name} @samp{flag}
> > +@end smallexample
> > +
> > +Set the frozeness flag on the variable object @var{name}. The
> > +@var{flag} parameter should be either @samp{1} to make the variable
>
> ``flag'' should be in @var in the example as well, not only in the
> text.
Here's an editorial patch based on comments from you, Dan and Nick. OK?
- Volodya
[-- Attachment #2: edits.diff --]
[-- Type: text/x-diff, Size: 2341 bytes --]
Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.403
diff -u -p -r1.403 gdb.texinfo
--- gdb.texinfo 14 Apr 2007 09:51:29 -0000 1.403
+++ gdb.texinfo 15 Apr 2007 10:34:14 -0000
@@ -17296,7 +17296,7 @@ New fields may be added to the output of
@item
The range of values for fields with specified values, e.g.,
-@code{in_scope} (@pxref{-var-update-fields}) may be extended.
+@code{in_scope} (@pxref{-var-update fields}) may be extended.
@c The format of field's content e.g type prefix, may change so parse it
@c at your own risk. Yes, in general?
@@ -19564,7 +19564,8 @@ list of variable objects whose values ha
be a root variable object. Here, ``changed'' means that the result of
@code{-var-evaluate-expression} before and after the
@code{-var-update} is different. If @samp{*} is used as the variable
-object names, all existing variable objects are updated. The option
+object names, all existing variable objects are updated, except
+for frozen ones (@pxref{-var-set-frozen}). The option
@var{print-values} determines whether both names and values, or just
names are printed. The possible values of this options are the same
as for @code{-var-list-children} (@pxref{-var-list-children}). It is
@@ -19585,7 +19586,7 @@ type_changed="false"@}]
(gdb)
@end smallexample
-@anchor{-var-update-fields}
+@anchor{-var-update fields}
The field in_scope may take three values:
@table @code
@@ -19610,16 +19611,17 @@ be prepared for this possibility. @xref
@subheading The @code{-var-set-frozen} Command
@findex -var-set-frozen
+@anchor{-var-set-frozen}
@subsubheading Synopsis
@smallexample
- -var-set-frozen @var{name} @samp{flag}
+ -var-set-frozen @var{name} @var{flag}
@end smallexample
-Set the frozeness flag on the variable object @var{name}. The
+Set the frozenness flag on the variable object @var{name}. The
@var{flag} parameter should be either @samp{1} to make the variable
-frozen or @samp{0} to make it unfozen. If a variable object is
+frozen or @samp{0} to make it unfrozen. If a variable object is
frozen, then neither itself, nor any of its children, are
implicitly updated by @code{-var-update} (@pxref{-var-update}) of
a parent variable or by @code{-var-update *}. Only
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-15 10:35 ` Vladimir Prus
@ 2007-04-15 11:46 ` Nick Roberts
2007-04-15 11:57 ` Vladimir Prus
2007-04-15 20:13 ` Eli Zaretskii
1 sibling, 1 reply; 33+ messages in thread
From: Nick Roberts @ 2007-04-15 11:46 UTC (permalink / raw)
To: Vladimir Prus; +Cc: Daniel Jacobowitz, Eli Zaretskii, gdb-patches
> > Also the name that is displayed shouldn't change, so pxref needs to be
> > called with two arguments:
> >
> >
> > @code{in_scope} (@pxref{-var-update fields, -var-update}) may be extended.
>
> That does not seem to work in a sensible way. In PDF, you get "-var-update
> fields" only, and info has:
>
> (*note -var-update: -var-update fields.)
>
> which makes no sense whatsoever.
It does to me because the first refers to the destination (the entry for
-var-update), while the second is just the name of the anchor which is not
visible to the reader. Info in Emacs reflects the importance of the first
argument by just displaying:
(*note -var-update.)
Currently Emacs displays:
(*note -var-update-fields.)
but there is no such (visible) location.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-15 11:46 ` Nick Roberts
@ 2007-04-15 11:57 ` Vladimir Prus
2007-04-15 20:09 ` Nick Roberts
2007-04-15 20:16 ` Eli Zaretskii
0 siblings, 2 replies; 33+ messages in thread
From: Vladimir Prus @ 2007-04-15 11:57 UTC (permalink / raw)
To: Nick Roberts; +Cc: Daniel Jacobowitz, Eli Zaretskii, gdb-patches
On Sunday 15 April 2007 15:40, Nick Roberts wrote:
> > > Also the name that is displayed shouldn't change, so pxref needs to be
> > > called with two arguments:
> > >
> > >
> > > @code{in_scope} (@pxref{-var-update fields, -var-update}) may be extended.
> >
> > That does not seem to work in a sensible way. In PDF, you get "-var-update
> > fields" only, and info has:
> >
> > (*note -var-update: -var-update fields.)
> >
> > which makes no sense whatsoever.
>
> It does to me because the first refers to the destination (the entry for
> -var-update), while the second is just the name of the anchor which is not
> visible to the reader.
It is visible to the reader -- both in printed documented and in info (as viewed
by 'info' command).
> Info in Emacs reflects the importance of the first
> argument by just displaying:
>
> (*note -var-update.)
>
> Currently Emacs displays:
>
> (*note -var-update-fields.)
>
> but there is no such (visible) location.
Should we really cater to the way Emacs displays something?
- Volodya
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-15 11:42 ` Vladimir Prus
@ 2007-04-15 12:03 ` Nick Roberts
2007-04-16 2:40 ` Eli Zaretskii
2007-04-15 20:14 ` Eli Zaretskii
1 sibling, 1 reply; 33+ messages in thread
From: Nick Roberts @ 2007-04-15 12:03 UTC (permalink / raw)
To: Vladimir Prus; +Cc: Eli Zaretskii, drow, gdb-patches
> Here's an editorial patch based on comments from you, Dan and Nick. OK?
It's Eli who decides, but having -var-update reference -var-set-frozen which in
turn references -var-update seems too complicated, and shouldn't be necessary
if there was a natural flow. Generally I just find this node much harder to
read than I used to.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-15 11:57 ` Vladimir Prus
@ 2007-04-15 20:09 ` Nick Roberts
2007-04-15 20:16 ` Eli Zaretskii
1 sibling, 0 replies; 33+ messages in thread
From: Nick Roberts @ 2007-04-15 20:09 UTC (permalink / raw)
To: Vladimir Prus; +Cc: Daniel Jacobowitz, Eli Zaretskii, gdb-patches
> > It does to me because the first refers to the destination (the entry for
> > -var-update), while the second is just the name of the anchor which is not
> > visible to the reader.
>
> It is visible to the reader -- both in printed documented and in info (as
> viewed by 'info' command).
The *anchor* isn't visible. Well I can't see it.
> > Info in Emacs reflects the importance of the first
> > argument by just displaying:
> >
> > (*note -var-update.)
> >
> > Currently Emacs displays:
> >
> > (*note -var-update-fields.)
> >
> > but there is no such (visible) location.
>
> Should we really cater to the way Emacs displays something?
Yes. GDB and Emacs are both part of the GNU Project, and it makes sense to
integrate tools, in any case.
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-15 10:35 ` Vladimir Prus
2007-04-15 11:46 ` Nick Roberts
@ 2007-04-15 20:13 ` Eli Zaretskii
1 sibling, 0 replies; 33+ messages in thread
From: Eli Zaretskii @ 2007-04-15 20:13 UTC (permalink / raw)
To: Vladimir Prus; +Cc: nickrob, drow, gdb-patches
> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Sun, 15 Apr 2007 14:31:57 +0400
> Cc: Daniel Jacobowitz <drow@false.org>,
> Eli Zaretskii <eliz@gnu.org>,
> gdb-patches@sources.redhat.com
>
> > @code{in_scope} (@pxref{-var-update fields, -var-update}) may be extended.
>
> That does not seem to work in a sensible way. In PDF, you get "-var-update fields"
> only
What would you like it to say? I suspect you want the version of
@pxref that uses more than 2 arguments, but that's a guess.
> (*note -var-update: -var-update fields.)
>
> which makes no sense whatsoever.
Why not? It makes perfect sense to me, but maybe I'm missing
something.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-15 11:42 ` Vladimir Prus
2007-04-15 12:03 ` Nick Roberts
@ 2007-04-15 20:14 ` Eli Zaretskii
1 sibling, 0 replies; 33+ messages in thread
From: Eli Zaretskii @ 2007-04-15 20:14 UTC (permalink / raw)
To: Vladimir Prus; +Cc: drow, gdb-patches
> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Sun, 15 Apr 2007 14:35:16 +0400
> Cc: drow@false.org,
> gdb-patches@sources.redhat.com
>
> Here's an editorial patch based on comments from you, Dan and Nick. OK?
Yes, thanks. But I'd like to reach a consensus on the anchor
reference issue raised by Nick.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-15 11:57 ` Vladimir Prus
2007-04-15 20:09 ` Nick Roberts
@ 2007-04-15 20:16 ` Eli Zaretskii
1 sibling, 0 replies; 33+ messages in thread
From: Eli Zaretskii @ 2007-04-15 20:16 UTC (permalink / raw)
To: Vladimir Prus; +Cc: nickrob, drow, gdb-patches
> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Sun, 15 Apr 2007 15:46:08 +0400
> Cc: Daniel Jacobowitz <drow@false.org>,
> Eli Zaretskii <eliz@gnu.org>,
> gdb-patches@sources.redhat.com
>
> Should we really cater to the way Emacs displays something?
It is one of the 2 most popular Info readers (and the better one of
them visually), so of course we should cater to it.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-15 12:03 ` Nick Roberts
@ 2007-04-16 2:40 ` Eli Zaretskii
2007-04-18 5:38 ` Vladimir Prus
0 siblings, 1 reply; 33+ messages in thread
From: Eli Zaretskii @ 2007-04-16 2:40 UTC (permalink / raw)
To: Nick Roberts; +Cc: vladimir, gdb-patches
> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sun, 15 Apr 2007 23:54:49 +1200
> Cc: Eli Zaretskii <eliz@gnu.org>, drow@false.org,
> gdb-patches@sources.redhat.com
>
> > Here's an editorial patch based on comments from you, Dan and Nick. OK?
>
> It's Eli who decides, but having -var-update reference -var-set-frozen which in
> turn references -var-update seems too complicated, and shouldn't be necessary
> if there was a natural flow.
I'm afraid I wasn't following this sub-thread closely enough, so
forgive me, Vladimir, if I ask what was already said: could you please
explain the rationale for your change of the anchors in this patch?
Thanks.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-16 2:40 ` Eli Zaretskii
@ 2007-04-18 5:38 ` Vladimir Prus
2007-04-18 10:37 ` Nick Roberts
2007-04-19 4:41 ` Eli Zaretskii
0 siblings, 2 replies; 33+ messages in thread
From: Vladimir Prus @ 2007-04-18 5:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Nick Roberts, gdb-patches
On Monday 16 April 2007 00:16, Eli Zaretskii wrote:
> > From: Nick Roberts <nickrob@snap.net.nz>
> > Date: Sun, 15 Apr 2007 23:54:49 +1200
> > Cc: Eli Zaretskii <eliz@gnu.org>, drow@false.org,
> > gdb-patches@sources.redhat.com
> >
> > > Here's an editorial patch based on comments from you, Dan and Nick. OK?
> >
> > It's Eli who decides, but having -var-update reference -var-set-frozen which in
> > turn references -var-update seems too complicated, and shouldn't be necessary
> > if there was a natural flow.
>
> I'm afraid I wasn't following this sub-thread closely enough, so
> forgive me, Vladimir, if I ask what was already said: could you please
> explain the rationale for your change of the anchors in this patch?
You've asked to add a reference to -var-update. There was already -var-update
anchor. However, that anchor was pointing in the middle of -var-update documentaiton,
so following the reference would land the reader at list of some attributes, which
would be confusing. And it seems that calling anchor for entire -var-update docs
as -var-update is more reasonable then using -var-update anchor for the list
of fields output by -var-update.
Does this clarify things?
- Volodya
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-10 19:03 ` Daniel Jacobowitz
2007-04-11 14:44 ` Vladimir Prus
@ 2007-04-18 5:38 ` Michael Snyder
2007-04-18 6:57 ` Vladimir Prus
1 sibling, 1 reply; 33+ messages in thread
From: Michael Snyder @ 2007-04-18 5:38 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Vladimir Prus, gdb-patches
On Tue, 2007-04-10 at 15:03 -0400, 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
I hate to jump in at this late date, but...
"frozenness".
Two n's.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-18 5:38 ` Ping: frozen variable objects Michael Snyder
@ 2007-04-18 6:57 ` Vladimir Prus
2007-04-18 22:21 ` Michael Snyder
0 siblings, 1 reply; 33+ messages in thread
From: Vladimir Prus @ 2007-04-18 6:57 UTC (permalink / raw)
To: Michael Snyder; +Cc: Daniel Jacobowitz, gdb-patches
On Wednesday 18 April 2007 00:52, Michael Snyder wrote:
> On Tue, 2007-04-10 at 15:03 -0400, 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
>
> I hate to jump in at this late date, but...
>
> "frozenness".
>
> Two n's.
There's already patch to fix that ;-)
- Volodya
^ permalink raw reply [flat|nested] 33+ messages in thread
* [patch] fix insight (was: Re: Ping: frozen variable objects)
2007-04-14 16:14 ` Vladimir Prus
` (2 preceding siblings ...)
2007-04-15 8:04 ` Nick Roberts
@ 2007-04-18 10:22 ` Brian Dessent
2007-04-18 12:51 ` Maciej W. Rozycki
3 siblings, 1 reply; 33+ messages in thread
From: Brian Dessent @ 2007-04-18 10:22 UTC (permalink / raw)
To: Vladimir Prus; +Cc: Eli Zaretskii, drow, gdb-patches, insight
[-- Attachment #1: Type: text/plain, Size: 415 bytes --]
Vladimir Prus wrote:
> Here's what I've just checked in. There was already -var-update anchor, but
> it was on the list of varobj attributes, so I've renamed it, and added -var-update
> anchor at the top of -var-update description.
This has unfortunately broken insight, which had one caller of
varobj_update lurking in gdbtk/generic/gdbtk-varobj.c that now fails due
to the extra paremeter. Fix attached.
Brian
[-- Attachment #2: insight_varobj_update.patch --]
[-- Type: text/plain, Size: 863 bytes --]
2007-04-18 Brian Dessent <brian@dessent.net>
* generic/gdbtk-varobj.c (variable_update): Add explicit parameter
to varobj_update.
Index: generic/gdbtk-varobj.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/generic/gdbtk-varobj.c,v
retrieving revision 1.19
diff -u -p -r1.19 gdbtk-varobj.c
--- generic/gdbtk-varobj.c 23 Dec 2005 18:23:16 -0000 1.19
+++ generic/gdbtk-varobj.c 18 Apr 2007 09:51:38 -0000
@@ -447,7 +447,7 @@ variable_update (Tcl_Interp *interp, str
/* varobj_update() can return -1 if the variable is no longer around,
i.e. we stepped out of the frame in which a local existed. */
- if (varobj_update (var, &changelist) == -1)
+ if (varobj_update (var, &changelist, 1 /* explicit */) == -1)
return Tcl_NewStringObj ("-1", -1);
changed = Tcl_NewListObj (0, NULL);
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-18 5:38 ` Vladimir Prus
@ 2007-04-18 10:37 ` Nick Roberts
2007-04-18 22:23 ` Eli Zaretskii
2007-04-19 4:41 ` Eli Zaretskii
1 sibling, 1 reply; 33+ messages in thread
From: Nick Roberts @ 2007-04-18 10:37 UTC (permalink / raw)
To: Vladimir Prus; +Cc: Eli Zaretskii, gdb-patches
> > > It's Eli who decides, but having -var-update reference -var-set-frozen
> > > which in turn references -var-update seems too complicated, and
> > > shouldn't be necessary if there was a natural flow.
> >
> > I'm afraid I wasn't following this sub-thread closely enough, so
> > forgive me, Vladimir, if I ask what was already said: could you please
> > explain the rationale for your change of the anchors in this patch?
>
> You've asked to add a reference to -var-update. There was already
> -var-update anchor. However, that anchor was pointing in the middle of
> -var-update documentaiton, so following the reference would land the reader
> at list of some attributes, which would be confusing. And it seems that
> calling anchor for entire -var-update docs as -var-update is more reasonable
> then using -var-update anchor for the list of fields output by -var-update.
>
> Does this clarify things?
For this case, I suggested using the existing pxref with two arguments (three
might be better still).
However, you're now adding another pxref and anchor, and the point I tried to
make above was that it shouldn't be necessary to have circular references
within a single node.
(Actually, as a rule of thumb, I would say it's a good idea not to have
references within one node at all, as it's not unreasonable to expect the
reader to, at least, skip read the whole node. If it is unresonable then the
node is probably too long. However, I'm not suggesting to take the first one
out too.)
--
Nick http://www.inet.net.nz/~nickrob
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [patch] fix insight (was: Re: Ping: frozen variable objects)
2007-04-18 10:22 ` [patch] fix insight (was: Re: Ping: frozen variable objects) Brian Dessent
@ 2007-04-18 12:51 ` Maciej W. Rozycki
2007-04-18 13:01 ` Brian Dessent
0 siblings, 1 reply; 33+ messages in thread
From: Maciej W. Rozycki @ 2007-04-18 12:51 UTC (permalink / raw)
To: gdb-patches; +Cc: Vladimir Prus, Eli Zaretskii, drow, insight
On Wed, 18 Apr 2007, Brian Dessent wrote:
> This has unfortunately broken insight, which had one caller of
> varobj_update lurking in gdbtk/generic/gdbtk-varobj.c that now fails due
> to the extra paremeter. Fix attached.
This is not enough as varobj_update() has to be wrapped these days --
please see:
http://sources.redhat.com/ml/insight/2007-q2/msg00012.html
The patch included there already contains a change like yours.
Maciej
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [patch] fix insight (was: Re: Ping: frozen variable objects)
2007-04-18 12:51 ` Maciej W. Rozycki
@ 2007-04-18 13:01 ` Brian Dessent
0 siblings, 0 replies; 33+ messages in thread
From: Brian Dessent @ 2007-04-18 13:01 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: gdb-patches, insight
"Maciej W. Rozycki" wrote:
> This is not enough as varobj_update() has to be wrapped these days --
> please see:
>
> http://sources.redhat.com/ml/insight/2007-q2/msg00012.html
>
> The patch included there already contains a change like yours.
Thanks, I must have glossed over that message. Obviously there's more
to it than I had thought.
Brian
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-18 6:57 ` Vladimir Prus
@ 2007-04-18 22:21 ` Michael Snyder
0 siblings, 0 replies; 33+ messages in thread
From: Michael Snyder @ 2007-04-18 22:21 UTC (permalink / raw)
To: Vladimir Prus; +Cc: Daniel Jacobowitz, gdb-patches
On Wed, 2007-04-18 at 09:38 +0400, Vladimir Prus wrote:
> On Wednesday 18 April 2007 00:52, Michael Snyder wrote:
> > On Tue, 2007-04-10 at 15:03 -0400, 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
> >
> > I hate to jump in at this late date, but...
> >
> > "frozenness".
> >
> > Two n's.
>
> There's already patch to fix that ;-)
>
> - Volodya
See? That's why I hate to jump in late! ;-O
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-18 10:37 ` Nick Roberts
@ 2007-04-18 22:23 ` Eli Zaretskii
0 siblings, 0 replies; 33+ messages in thread
From: Eli Zaretskii @ 2007-04-18 22:23 UTC (permalink / raw)
To: Nick Roberts; +Cc: vladimir, gdb-patches
> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Wed, 18 Apr 2007 22:20:34 +1200
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sources.redhat.com
>
> However, you're now adding another pxref and anchor, and the point I tried to
> make above was that it shouldn't be necessary to have circular references
> within a single node.
If the pxref is to the same node, it is indeed unnecessary. If that
happened because I asked to add a reference, then I'm sorry; please
replace the reference with something like ``(see the description of
-var-update fields above)''.
> (Actually, as a rule of thumb, I would say it's a good idea not to have
> references within one node at all
Right.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Ping: frozen variable objects
2007-04-18 5:38 ` Vladimir Prus
2007-04-18 10:37 ` Nick Roberts
@ 2007-04-19 4:41 ` Eli Zaretskii
1 sibling, 0 replies; 33+ messages in thread
From: Eli Zaretskii @ 2007-04-19 4:41 UTC (permalink / raw)
To: Vladimir Prus; +Cc: nickrob, gdb-patches
> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Wed, 18 Apr 2007 09:38:17 +0400
> Cc: Nick Roberts <nickrob@snap.net.nz>,
> gdb-patches@sources.redhat.com
>
> Does this clarify things?
Yes, thanks. Your reasoning is entirely correct, but it sounds like I
talked you into adding a reference to the same node, which is not good
Texinfo usage. Sorry about that.
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2007-04-18 22:23 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-25 9:52 Ping: frozen variable objects Vladimir Prus
2007-03-25 20:17 ` Eli Zaretskii
2007-04-10 19:03 ` Daniel Jacobowitz
2007-04-11 14:44 ` Vladimir Prus
2007-04-11 14:52 ` Daniel Jacobowitz
2007-04-11 18:38 ` Eli Zaretskii
2007-04-13 9:53 ` Eli Zaretskii
2007-04-14 16:14 ` Vladimir Prus
2007-04-14 16:19 ` Daniel Jacobowitz
2007-04-14 23:18 ` Nick Roberts
2007-04-15 10:32 ` Vladimir Prus
2007-04-15 10:35 ` Vladimir Prus
2007-04-15 11:46 ` Nick Roberts
2007-04-15 11:57 ` Vladimir Prus
2007-04-15 20:09 ` Nick Roberts
2007-04-15 20:16 ` Eli Zaretskii
2007-04-15 20:13 ` Eli Zaretskii
2007-04-14 20:32 ` Eli Zaretskii
2007-04-15 11:42 ` Vladimir Prus
2007-04-15 12:03 ` Nick Roberts
2007-04-16 2:40 ` Eli Zaretskii
2007-04-18 5:38 ` Vladimir Prus
2007-04-18 10:37 ` Nick Roberts
2007-04-18 22:23 ` Eli Zaretskii
2007-04-19 4:41 ` Eli Zaretskii
2007-04-15 20:14 ` Eli Zaretskii
2007-04-15 8:04 ` Nick Roberts
2007-04-18 10:22 ` [patch] fix insight (was: Re: Ping: frozen variable objects) Brian Dessent
2007-04-18 12:51 ` Maciej W. Rozycki
2007-04-18 13:01 ` Brian Dessent
2007-04-18 5:38 ` Ping: frozen variable objects Michael Snyder
2007-04-18 6:57 ` Vladimir Prus
2007-04-18 22:21 ` Michael Snyder
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox