[PATCH] Forward VALUE_LVAL when avoiding side effects for STRUCTOP_STRUCT

[Pierre-Marie de Rodat]

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