OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

* 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.
This commit is contained in:
Ulrich Weigand 2010-12-01 16:49:41 +00:00
parent 04276a0cf5
commit 4aac0db70f
3 changed files with 32 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
gdb/ChangeLog
View File

@ -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

6
gdb/NEWS
View File

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

25
gdb/valops.c
View File

@ -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;
}