Re: [patch 11/12] entryval#2: @entry values even for references

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Fri, 23 Sep 2011 11:50:22 +0200, Pedro Alves wrote:
> Sorry, in the hurry, I hadn't noticed you had used `S &s; class S { char a, b; };'.
> That's not the case I raised originally.  The case is an entry val of
> type `struct { int a; long &b; }'.  Calling an entry object of that
> type `s', if we "print s@entry", I think we'll:

In such case the parameter `s' is not TYPE_CODE_REF and therefore
entry_data_value_funcs do not get ever used and therefore
coerce_ref_if_computed will always return NULL.

coerce_ref_if_computed is there only as a hack for TYPE_CODE_REF which
dereferences into something else than what a native normal such
TYPE_CODE_REF-pointer would derefefence into.

I had a former version of the patch which did not use coerce_ref_if_computed
and if it has seen TYPE_CODE_REF with both DW_AT_GNU_call_site_value (=the
pointer) and DW_AT_GNU_call_site_data_value (=the dereferenced data) then it
created non-lazy lval_memory object of TYPE_TARGET_TYPE type with
value_address set to that reference-pointer. But such case was (a) confusing
because `ptype param' and `ptype param@entry' could be different and (b)
dangerous as param@entry was modifiable due to its lval_memory (it is not_lval
now).


> print A (TYPE_CODE_INT) at embedded_offset 0 of S, and then B
> at embedded_offset==offsetof(typeof(s), b) of S (e.g., 8).  B will
> be TYPE_CODE_REF here, and coerce_ref_if_computed on S will wrongly

coerce_ref_if_computed will be NULL as there is no coerce_ref_if_computed
anywhere present.

> operate on the contents of the whole S (because it loses embedded_offset),
> instead of working with the B contents of S.


Thanks,
Jan