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 12:39:41, Jan Kratochvil wrote:
> 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 see, thanks. Okay, let's go with this, with the
embedded_offset == 0 assertion in place.
I really dislike lval_computed special casing. We should be
aiming at making it generic enough to be able to reimplement the
regular lval_memory/lval_register, etc. lval types as lval_computed,
hence my insistence.
--
Pedro Alves