This is the mail archive of the gdb-patches@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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; } }