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

[Pedro Alves <pedro@codesourcery.com>]

On Friday 23 September 2011 09:30:32, Jan Kratochvil wrote:
> 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.

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:

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
operate on the contents of the whole S (because it loses embedded_offset),
instead of working with the B contents of S.

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

-- 
Pedro Alves