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 01:42:02 +0200, Pedro Alves wrote:
> Just a quick reply, can't reply in full now:
> 
> On Thursday 22 September 2011 22:47:53, Jan Kratochvil wrote:
> > (b) Even if I create such DWARF attribute by hand the expression `s@entry.b'
> >     for parameter `S &s' of type `class S { char a, b; };' never reaches this
> >     point of code because:
> 
> That's not the case that descends into subfields of an object with
> embedded_offset != 0.  It's when printing the _whole struct_, and
> gdb goes and prints a at embedded_offset 0 of s, and then b at
> embedded_offset==offsetof(typeof(s), b) of s.
> 
> Try "p s@entry" ?

First c_val_print enters with TYPE_CODE_REF, embedded_offset==0 being
lval_computed with entry_data_value_funcs.

coerce_ref_if_computed succeeds, returning deref_val with TYPE_CODE_STRUCT,
embedded_offset==0 being lval_memory at some inferior address.

In this moment common_val_print is called with this new lval_memory value, the
former original_value with lval_computed is forgotten, there is no longer
anything non-standard (anything related to entry_data_value_funcs).

c_val_print cannot use for TYPE_CODE_REF coerce_ref as it has to respect
embedded_offset and the current sub-type etc.  This is needed for the case of
foo.r in `struct { long l; long &r } foo;'.  But the difference with
entry_data_value_funcs is that such value can never be a part of anything
else, it is always a toplevel value.  embedded_offset != 0 for
entry_data_value_funcs would try to take the reference-pointer from some
shifted (and invalid) location.  embedded_offset != 0 for
entry_data_value_funcs does not express the offset in the target structure
(pointed_to_offset would express that).

Entry values are not self-contained, they can reference other data which are
no longer in the entry-time state.  This is a defect of the design but fixing
that would mean probably excessive and unbound debug info sizes.


Thanks,
Jan