Re: [python] Should pretty-printer affect resulting gdb-history value?

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Paul" == Paul Pluzhnikov <ppluzhnikov@google.com> writes:

Paul> (gdb) print s
Paul> $3 = 0x7fffffffe5dc          # pretty-printer worked,
Paul>                              # but why didn't it also print "(int *)" ?

I don't know why it didn't print "(int *)".
Maybe it is done at a different place in the print code.

Paul> (gdb) whatis $3              # not at all what I would have expected...
Paul> type = struct S
Paul> (gdb) print *$3
Paul> Structure has no component named operator*.

The original idea behind pretty-printing was that it would change the
display only.  A supporting idea was that we would print the accessor
information on the left-hand-side.

So according to the original plan it would look like:

(gdb) print s
$3.ptr = 0x7fffffffe5dc

Or:

(gdb) print vec
$4[0] = ...
$4[1] = ...


I looked into this a little, though, and it seemed like a major
overhaul of all the print code, which was way too much to do.  (I've
been mostly trying to keep the Python changes non-invasive, so that
maintaining them isn't a huge burden; and if I do need a big basic
change, I try to do it upstream first.)

I didn't dig here as much as I should have.  Maybe I'm wrong about how
hard it is.

Also, after writing a few printers, I was concerned about how big the
LHS might get.  This isn't so bad in C++, where there are often useful
access operators; but pretty-printing a linked list in C would be
awful.

A vestige of this lurks in how we sometimes display the names of
children.  The intent was that these be usable as accessors -- at
least assuming that operator overloading worked properly in all cases
(which it doesn't today, but it is another goal of Archer, so I felt
free to assume it).

There is a parallel problem for varobjs here.  Really the children
ought to be separately inspectable but I don't think we make much
effort to ensure this is true.  I have done way less testing of this
than I should :-(


Anyway, that explains how we got where we are.  I'm not sure where we
should go.

On the one hand, yeah, pretty-printing shows a strange view of the
world: it changes the printout but then you can't operate directly on
what you see.

On the other hand, it also seems strange for an expression's value to
change.

Also, we have to consider sub-values.  Suppose you also had

struct T { struct S s; } t;

Then, e.g.:

(gdb) print t
$1 = {
  s = 0x7fffffffe5dc
}

So, "print *t.s" ought to dereference... but at this point we would
need to muck around with rewriting the fields somehow -- and
synthesizing a new structure type, because "s" would have a different
type.

Paul> I think it would make sense for the type of $2 and $3 to match,
Paul> though I have no idea whether that's implementable.

It would require a hack somewhere, say a callback to rewrite the value
history.  I'm not super concerned about that.

Tom