From 4aac0db70f3720574c1e9102b7e2ca0d8c3390f6 Mon Sep 17 00:00:00 2001 From: Ulrich Weigand Date: Wed, 1 Dec 2010 16:49:41 +0000 Subject: [PATCH] * valops.c (value_assign): Returned value is never lazy. If a C++ class type is returned, fix incorrect enclosing type / embedded offset. If internal variable is returned, allocate new internalvar value using value_of_internalvar. * NEWS: Document changes in behavior of "print x = 0" and similar expressions. --- gdb/ChangeLog | 10 ++++++++++ gdb/NEWS | 6 ++++++ gdb/valops.c | 25 ++++++++++++++++--------- 3 files changed, 32 insertions(+), 9 deletions(-) diff --git a/gdb/ChangeLog b/gdb/ChangeLog index 0286cac408e..ad7278d1e8a 100644 --- a/gdb/ChangeLog +++ b/gdb/ChangeLog @@ -1,3 +1,13 @@ +2010-12-01 Ulrich Weigand + + * valops.c (value_assign): Returned value is never lazy. If a + C++ class type is returned, fix incorrect enclosing type / embedded + offset. If internal variable is returned, allocate new internalvar + value using value_of_internalvar. + + * NEWS: Document changes in behavior of "print x = 0" and similar + expressions. + 2010-11-29 Doug Evans * python/lib/gdb/printing.py (register_pretty_printer): Change diff --git a/gdb/NEWS b/gdb/NEWS index 38478c4542a..f1efcd2b3e8 100644 --- a/gdb/NEWS +++ b/gdb/NEWS @@ -46,6 +46,12 @@ feature requires proper debuginfo support from the compiler; it was added to GCC 4.5. +* GDB now follows GCC's rules on accessing volatile objects when + reading or writing target state during expression evaluation. + One notable difference to prior behavior is that "print x = 0" + no longer generates a read of x; the value of the assignment is + now always taken directly from the value being assigned. + * GDB now has some support for using labels in the program's source in linespecs. For instance, you can use "advance label" to continue execution to a label. diff --git a/gdb/valops.c b/gdb/valops.c index e115b311302..dfadad896d7 100644 --- a/gdb/valops.c +++ b/gdb/valops.c @@ -1138,11 +1138,8 @@ value_assign (struct value *toval, struct value *fromval) { case lval_internalvar: set_internalvar (VALUE_INTERNALVAR (toval), fromval); - val = value_copy (fromval); - set_value_enclosing_type (val, value_enclosing_type (fromval)); - set_value_embedded_offset (val, value_embedded_offset (fromval)); - set_value_pointed_to_offset (val, value_pointed_to_offset (fromval)); - return val; + return value_of_internalvar (get_type_arch (type), + VALUE_INTERNALVAR (toval)); case lval_internalvar_component: set_internalvar_component (VALUE_INTERNALVAR (toval), @@ -1328,13 +1325,23 @@ value_assign (struct value *toval, struct value *fromval) fromval = value_from_longest (type, fieldval); } + /* The return value is a copy of TOVAL so it shares its location + information, but its contents are updated from FROMVAL. This + implies the returned value is not lazy, even if TOVAL was. */ val = value_copy (toval); + set_value_lazy (val, 0); memcpy (value_contents_raw (val), value_contents (fromval), TYPE_LENGTH (type)); - deprecated_set_value_type (val, type); - set_value_enclosing_type (val, value_enclosing_type (fromval)); - set_value_embedded_offset (val, value_embedded_offset (fromval)); - set_value_pointed_to_offset (val, value_pointed_to_offset (fromval)); + + /* We copy over the enclosing type and pointed-to offset from FROMVAL + in the case of pointer types. For object types, the enclosing type + and embedded offset must *not* be copied: the target object refered + to by TOVAL retains its original dynamic type after assignment. */ + if (TYPE_CODE (type) == TYPE_CODE_PTR) + { + set_value_enclosing_type (val, value_enclosing_type (fromval)); + set_value_pointed_to_offset (val, value_pointed_to_offset (fromval)); + } return val; } -- 2.30.2