Re: bokenness of nested pretty printers

["Paul Pluzhnikov" <ppluzhnikov at google dot com>]

On Thu, Oct 16, 2008 at 12:13 PM, Tom Tromey <tromey@redhat.com> wrote:

>>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:
>
> Paul> I think fixing this requires either that we pass down 'value' itself,
> Paul> or at least 'value->offset'.
>
> Thanks.  Nice analysis.
>
> Paul> Comments?
>
> I notice c-valprint.c does:
>
>  return val_print (type, value_contents_all (val),
>                    value_embedded_offset (val),
>                    VALUE_ADDRESS (val) + value_offset (val),
>
> That last line seems to indicate the answer.

Yes, I forgot to mention the 'adjust address when calling
val_print()' alternative.

> Strangely, many calls to val_print do not do this.

I think this may just be a 'problem waiting to happen' (see below).

> I wonder why VALUE_ADDRESS does not do this addition itself.

I don't quite understand why 'offset' is even needed (and GDB
internals is silent on the whole 'what are values' subject :(

> The appended fixes this particular instance of the problem for me.
> Of course, we'd have to audit all the calls to make sure the problem
> is fully fixed.

Indeed.

Here is a modification to the original which shows that
val_print_array_elements() is similarly broken:

int
main ()
{
  struct ss  ss;
  struct ss  ssa[2];

  init_ss(&ss, 1, 2);
  init_ss(ssa+0, 3, 4);
  init_ss(ssa+1, 5, 6);
  return 0;      /* break to inspect struct and union */
}


With your patch, 'print ssa[0]' and 'print ssa[1]' work fine, but
'print ssa' results in:

(gdb) p ssa
$4 = {Traceback (most recent call last):
  File "<string>", line 6, in pp_s
Exception: &a(0x0) != b(0x7fffffffe5d0)
Traceback (most recent call last):
  File "<string>", line 6, in pp_s
Exception: &a(0x10) != b(0x7fffffffe5e0)
a={{a = 3, b = 0x7fffffffe5d0}} b={{a = 4, b = 0x7fffffffe5e0}},
Traceback (most recent call last):
  File "<string>", line 6, in pp_s
Exception: &a(0x0) != b(0x7fffffffe5f0)
Traceback (most recent call last):
  File "<string>", line 6, in pp_s
Exception: &a(0x10) != b(0x7fffffffe600)
a={{a = 5, b = 0x7fffffffe5f0}} b={{a = 6, b = 0x7fffffffe600}}}


> What do you think of this approach?

I don't understand 'values' enough to have an opinion,
but it seems pretty error-prone to require every user to do this...

If 'offset' is really necessary, then I think VALUE_ADDRESS()
or something similar ought to add 'offset' automatically.

Thanks,
-- 
Paul Pluzhnikov