This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Forward VALUE_LVAL when avoiding side effects for STRUCTOP_STRUCT

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

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


Pierre-Marie de Rodat

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]