questions about constructing value_ptr in read_var_value

questions about constructing value_ptr in read_var_value

[J.T. Conklin]

I discovered an anomaly in can_use_hardware_watchpoint() --- it
returns true if the expression is a variable in a register.

I discovered that read_var_value() allocates a node, which is usually
filled in with the addr of the variable; but in the case of variables
stored in registers, a new node is created with value_from_register()
and returned.  However, because the way value_ptr nodes are created,
the original, partially initialized (with lval_memory type), node is
still on the list of values.

When can_use_hardware_watchpoint() evaluates the list, it sees the
(extra) node with lval_memory type, and decides hardware watchpoints
can be used. (actually, I think this is another, different, bug.  The
function is supposed to ensure all intermediate values are in memory,
but it appears that register variables aren't rejected.  Thus a "reg
.op. mem" expression would be considered acceptable for a hardware
watchpoint.)

The enclosed patch avoids the extra node, by deleting the one
allocated at the top of read_var_value().  But perhaps the function
should avoid allocating it at all if SYMBOL_CLASS(var) == LOC_REGISTER
or LOC_REGPARM.

	--jtc

Index: findvar.c
===================================================================
RCS file: /usr/rback/release/tools-src/gdb/gdb/findvar.c,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 findvar.c
*** findvar.c	1999/01/28 22:58:50	1.1.1.3
--- findvar.c	1999/01/29 23:15:12
***************
*** 1325,1330 ****
--- 1325,1335 ----
  
  	    if (regval == NULL)
  	      error ("Value of register variable not available.");
+ 
+ 	    /* XXX Must release node we're not using */
+ 	    release_value (v);
+ 	    value_free (v);
+ 
  	    return regval;
  	  }
        }

questions about constructing value_ptr in read_var_value

[J.T. Conklin]

I discovered an anomaly in can_use_hardware_watchpoint() --- it
returns true if the expression is a variable in a register.

I discovered that read_var_value() allocates a node, which is usually
filled in with the addr of the variable; but in the case of variables
stored in registers, a new node is created with value_from_register()
and returned.  However, because the way value_ptr nodes are created,
the original, partially initialized (with lval_memory type), node is
still on the list of values.

When can_use_hardware_watchpoint() evaluates the list, it sees the
(extra) node with lval_memory type, and decides hardware watchpoints
can be used. (actually, I think this is another, different, bug.  The
function is supposed to ensure all intermediate values are in memory,
but it appears that register variables aren't rejected.  Thus a "reg
.op. mem" expression would be considered acceptable for a hardware
watchpoint.)

The enclosed patch avoids the extra node, by deleting the one
allocated at the top of read_var_value().  But perhaps the function
should avoid allocating it at all if SYMBOL_CLASS(var) == LOC_REGISTER
or LOC_REGPARM.

	--jtc

Index: findvar.c
===================================================================
RCS file: /usr/rback/release/tools-src/gdb/gdb/findvar.c,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 findvar.c
*** findvar.c	1999/01/28 22:58:50	1.1.1.3
--- findvar.c	1999/01/29 23:15:12
***************
*** 1325,1330 ****
--- 1325,1335 ----
  
  	    if (regval == NULL)
  	      error ("Value of register variable not available.");
+ 
+ 	    /* XXX Must release node we're not using */
+ 	    release_value (v);
+ 	    value_free (v);
+ 
  	    return regval;
  	  }
        }