Re: [PATCH] gdb: user variables with components of dynamic type

[Joel Brobecker <brobecker@adacore.com>]

Hi Andrew,

> Sorry for the length of time it has taken me to get back to you.
> Initially I was just chewing over your feedback, then I got
> sidetracked.....
> 
> I have a question about what you wrote, see inline below.
> > > I would not like to change Fortran from displaying dynamnic types as
> > > their actual value (and instead just display a pointer) as that seems
> > > like a really bad change just to work around a limitation with
> > > internal variables.
> > 
> > 100% agreed.
> 
> That's good, and not really surprising as from what you wrote I think
> this is what Ada does, but then later on you write...
> 
> > 
> > > What I think is super interesting is how this all interacts with
> > > pretty-printers.  So, if I start with this test program:
> > 
> > Interesting indeed.
> > 
> > > I wonder if this problem should just be solved (at least in the
> > > short/medium term) by improving the documentation for internal
> > > variables?
> > 
> > For me, if I had to summarize my current thinking thanks to our
> > discussions so far, I would say:
> > 
> >   (a) The case of fields whose type is dynamic is really very
> >       similar to the case of references.
> > 
> >   (b) Since we handle references the same as pointers, I think
> >       it's fine as a first instance to fix our immediate issue,
> >       which is the internal error, by providing the exact same
> >       kind of behavior for those dynamic fields as we provide
> >       for references.
> 
> ...this.
> 
> Aren't you here arguing that we should immediately fix this issue by
> changing the way dynamic types are printed such that they are handled
> more like C++ references (i.e. print the address rather than the
> contents).  Which seems to be the complete opposite of your opinion
> above.

It does like a contradiction indeed. I must have had a brainfarting
moment when I wrote that -- very sorry!

> I'm curious, if Ada makes use of dynamic typing then what does GDB
> print when an object of dynamic type is nested within some other
> object?

Ada resolves the dynamic object, and presents the actual type.
Reference layers are also silently peeled (we may need to rediscuss
the "silently" part, but that would be a separate discussion).
I don't have a full map of the various possibilities, but it's not
unusual for the "variable" part of an object to be replaced by
a reference. It's not always replaced by a reference, though.

> What happens if the parent object is assigned to a user variable?

Tom was recently asked about something like that, when one of
our developers had a situation where the value of something stored
in $1 was changing over time, and was surprised by that.

Only the contents of the value that's "directly accessible" to
re-use Tom's words, are captured. The printing of an object in
Ada can involve some silent dereferencing and the de-referenced
data is not captured. So re-printing a captured value can yield
a different answer.

> I guess given your concerns then the idea solution here would be one
> that somehow allows GDB to capture all of the dynamic content at the
> time the user variable is created.  I'll try to figure out if there's
> any good ways to achieve this.

That would definitely be ideal, absolutely. But it does sound like
a significant undertaking. Just thinking of the simple case of
a record with one field being a reference. How do go from capturing
a buffer with the contents of the record, to a case where we have
to have part of that buffer be treated specially so as to know that
the data targetted by the corresponding field is not obtained by
dereferencing the pointer, but by reading something elsewhere.

So, for me, what this discussion has helped me with is that
perhaps the best compromise is to do what's right when printing
the value of an expression, and then accept that the value
capturing method has a limitation that references are captured
as pointers, and that therefore that the captured data is not
entirely complete and may change while the inferior runs further.

Or said differently, if I remember what your patch is trying to do,
you've helped me come to the same conclusion as the one you reached
back when you proposed the patch.

> >   (c) Finding a way to make this clearer for users would be a nice
> >       enhancement, but this would be a general enhancement, not
> >       something required in the context of your patch.
> > 
> > So you and I are converging towards the same solution in the code,
> > and I agree that a documentation update might be useful as well.
> > 
> > Going back to your original patch, I would need more research
> > than what I have time for to determine whether I'd fix it
> > the same way you did at the location you did. After much staring
> > with the entire function's implementation as a context, the patch
> > does make sense to me, especially if I ignore a bit the asserts
> > for a minute.  Hopefully others with a more complete knowledge of
> > the area of value-saving for the value history can chime in.
> > 
> > I wish I could be more help! :-/
> > 
> > -- 
> > Joel
> > 
> > [1] I know your situation has to do with dynamic types rather than
> > references, but I think both cases are in the same boat and could
> > be treated the same.

-- 
Joel