This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 11/12] entryval#2: @entry values even for references
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