aboutsummaryrefslogtreecommitdiff
path: root/gdb/eval.c
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2021-01-08 14:00:45 +0000
committerAndrew Burgess <andrew.burgess@embecosm.com>2021-02-24 15:51:29 +0000
commitbc3c0632a2ebec04ad8c3c320dc8e9852bd2aabe (patch)
tree19271e5181a642045479585530955ec9f3a693ed /gdb/eval.c
parent9d3fcfe06896afd0ef1df4b22355d3822ca89e08 (diff)
downloadbinutils-bc3c0632a2ebec04ad8c3c320dc8e9852bd2aabe.zip
binutils-bc3c0632a2ebec04ad8c3c320dc8e9852bd2aabe.tar.gz
binutils-bc3c0632a2ebec04ad8c3c320dc8e9852bd2aabe.tar.bz2
gdb: call value_ind for pointers to dynamic types in UNOP_IND evaluation
When evaluating and expression containing UNOP_IND in mode EVAL_AVOID_SIDE_EFFECTS, GDB currently (mostly) returns the result of a call to value_zero meaning we get back an object with the correct type, but its contents are all zero. If the target type contains fields with dynamic type then in order to resolve these dynamic fields GDB will need to read the value of the field from within the parent object. In this case the field value will be zero as a result of the call to value_zero mentioned above. The idea behind EVAL_AVOID_SIDE_EFFECTS is to avoid the chance that doing something like `ptype` will modify state within the target, for example consider: ptype i++. However, there is already precedence within GDB that sometimes, in order to get accurate type results, we can't avoid reading from the target, even when EVAL_AVOID_SIDE_EFFECTS is in effect. For example I would point to eval.c:evaluate_var_value, the handling of OP_REGISTER, the handling of value_x_unop in many places. I believe the Ada expression evaluator also ignore EVAL_AVOID_SIDE_EFFECTS in some cases. I am therefor proposing that, in the case where a pointer points at a dynamic type, we allow UNOP_IND to perform the actual indirection. This allows accurate types to be displayed in more cases. gdb/ChangeLog: * eval.c (evaluate_subexp_standard): Call value_ind for points to dynamic types in UNOP_IND. gdb/testsuite/ChangeLog: * gdb.fortran/pointer-to-pointer.exp: Additional tests.
Diffstat (limited to 'gdb/eval.c')
-rw-r--r--gdb/eval.c36
1 files changed, 23 insertions, 13 deletions
diff --git a/gdb/eval.c b/gdb/eval.c
index 8256fde..7ba3ee5 100644
--- a/gdb/eval.c
+++ b/gdb/eval.c
@@ -2425,19 +2425,29 @@ evaluate_subexp_standard (struct type *expect_type,
else if (noside == EVAL_AVOID_SIDE_EFFECTS)
{
type = check_typedef (value_type (arg1));
- if (type->code () == TYPE_CODE_PTR
- || TYPE_IS_REFERENCE (type)
- /* In C you can dereference an array to get the 1st elt. */
- || type->code () == TYPE_CODE_ARRAY
- )
- return value_zero (TYPE_TARGET_TYPE (type),
- lval_memory);
- else if (type->code () == TYPE_CODE_INT)
- /* GDB allows dereferencing an int. */
- return value_zero (builtin_type (exp->gdbarch)->builtin_int,
- lval_memory);
- else
- error (_("Attempt to take contents of a non-pointer value."));
+
+ /* If the type pointed to is dynamic then in order to resolve the
+ dynamic properties we must actually dereference the pointer.
+ There is a risk that this dereference will have side-effects
+ in the inferior, but being able to print accurate type
+ information seems worth the risk. */
+ if ((type->code () != TYPE_CODE_PTR
+ && !TYPE_IS_REFERENCE (type))
+ || !is_dynamic_type (TYPE_TARGET_TYPE (type)))
+ {
+ if (type->code () == TYPE_CODE_PTR
+ || TYPE_IS_REFERENCE (type)
+ /* In C you can dereference an array to get the 1st elt. */
+ || type->code () == TYPE_CODE_ARRAY)
+ return value_zero (TYPE_TARGET_TYPE (type),
+ lval_memory);
+ else if (type->code () == TYPE_CODE_INT)
+ /* GDB allows dereferencing an int. */
+ return value_zero (builtin_type (exp->gdbarch)->builtin_int,
+ lval_memory);
+ else
+ error (_("Attempt to take contents of a non-pointer value."));
+ }
}
/* Allow * on an integer so we can cast it to whatever we want.