From: Ulrich Weigand <uweigand@de.ibm.com>
Date: Wed, 1 Dec 2010 16:49:41 +0000 (+0000)
Subject: 	* valops.c (value_assign): Returned value is never lazy.  If a
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=4aac0db70f3720574c1e9102b7e2ca0d8c3390f6;p=binutils-gdb.git

	* 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.
---

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  <uweigand@de.ibm.com>
+
+	* 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  <dje@google.com>
 
 	* 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;
 }