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