This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Forward VALUE_LVAL when avoiding side effects for STRUCTOP_STRUCT
- From: Pierre-Marie de Rodat <derodat at adacore dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 28 Sep 2015 13:03:51 +0200
- Subject: Re: [PATCH] Forward VALUE_LVAL when avoiding side effects for STRUCTOP_STRUCT
- Authentication-results: sourceware.org; auth=none
- References: <1442325448-27163-1-git-send-email-derodat at adacore dot com> <20150924132427 dot GC10139 at adacore dot com>
Thanks for reviewing, Joel!
On 09/24/2015 03:24 PM, Joel Brobecker wrote:
I'm not really sure this is a good idea to be doing that. We're building
somewhat of a fake "struct value", and the value's "discriminant" should,
in my mind at least, always reflect that through setting the lval to
"not_lval".
Have you tried modifying this function's handling of UNOP_ADDR
in the case of EVAL_AVOID_SIDE_EFFECTS instead? Add some code there
to return a not_lval value_zero with the correct type...
Ignoring that we have a not_lval operand for UNOP_ADDR in this mode
affects type resolution. In particular, I observed the following
regression (from gdb.base/ptype.exp):
(gdb) ptype *&{4,5,6}[1]
type = int
# The testsuite expects:
# Attempt to take address of value not located in memory.
My previous attempt in the case STRUCTOP_STRUCT preserves this
(important) information in EVAL_AVOID_SIDE_EFFECTS mode so we do not
have this kind of regression.
I donât really understand why fake values must be not_lval: is this
documented somewhere? After all, code is not supposed to use the content
of fake values (but only their types and other similar attributes),
right? Besides not all not_lval are fake values.
Beyond this, I have no idea about how to cleanly fix the original bug.
+# Sanity checking:
+gdb_test "print &foo_array\[1\].a" "= \\(int \\*\\) 0x.*"
Use "$hex.*" instead of "0x.*"...
Fixed.
--
Pierre-Marie de Rodat