[PATCH v2][PR gdb/19893] Fix handling of synthetic C++ references

[Martin Galvan]

Thanks for the answer!

On Tue, May 24, 2016 at 7:46 AM, Pedro Alves <palves@redhat.com> wrote:
> ... I still don't know what to think of this -- I simply don't understand it whether
> you're doing this because it makes sense, or because doing otherwise would be hard
> to do?

>From a consistency point of view, it's probably not the right thing.
All of the synthetic pointer cases I've tested always show "<synthetic
pointer>" instead of "@address".

As for how to fix it, yeah, it would be hard. Or at least I don't know
how to do it off the top of my head. I'd have to make value_addr not
return a not_lval when passing it a synthetic ref, which I'm not sure
it's right either.

I *could*, however, manually call
value->location.computed.funcs->check_synthetic_pointer in
generic_val_print_ref instead of using value_bits_synthetic_pointer,
thus avoiding the check for lval_computed. But that's a bit ugly IMHO.

> - Can you show an example output?  (set print object on/off, etc. whatever might be
>   handy to clearly explain that that is about).
>   Pictures are really worth a thousand words.  :-)

Sure:

(gdb) set print object off
(gdb) print ref
$3 = (S &) <synthetic pointer>: {
  a = 0,
  b = 1,
  c = 2
}
(gdb) set print object on
(gdb) print ref
$4 = (S &) @0x601038: {
  a = 0,
  b = 1,
  c = 2
}

Here, 0x601038 is the address of the structure 'ref' is referencing.
This is consistent with the output for non-synthetic references, where
the referenced value's address is shown.

> - Is this covered by any testcase?  I looked for "object" in the whole patch and
>   didn't seem to find it.

Not that I know of. Should I add a test for this to implref-struct?