Re: [RFA] valprint.c / *-valprint.c: Don't lose `embedded_offset'

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> A bit of explaining on why this is necessary.  In the context of
Pedro> tracepoints, I'm adding support for partial/incomplete objects.
Pedro> That is, say, when printing an array where only a few elements
Pedro> have been collected, print what you can, and print something like
Pedro> "<unavailable>" (like <optimized out>) for what has not been
Pedro> collected.

Looks nice.

Pedro> Trouble is in languages other than C/C++ where the
Pedro> advance-embedded_offset-don't-touch-valaddr-or-address contract
Pedro> isn't compromised in many places.

I think the embedded_offset is very confusing.  Every time I have to fix
a bug in it, I have to re-learn what it really means.  Perhaps next time
I will plan ahead and fix the commentary in value.c to be more clear (to
me at least).

Pedro> I have no way of testing the D or SCM changes, though the former's
Pedro> are quite small, and the latter's, I'm not sure who cares at all.

My belief is that gdb's guile support has bit-rotted -- specifically,
that guile has changed incompatibly.

I will ask.  Perhaps we can remove it.

Pedro> All in all, I think it's just better to be consistent throughout.
Pedro> I know I got mighty confused with some functions taking adjusted
Pedro> `valaddr' and `address', while others taking `embedded_offset'
Pedro> into account.  Maybe some day we will not allow passing around
Pedro> a NULL `val', and thus we will be able to get rid of `valaddr'
Pedro> and `address' parameters throughout, and instead get those from
Pedro> the value directly.  I don't plan to actually do that, but
Pedro> this seems like a step in that direction.

I was going to do this last time I had to add a parameter to the whole
val_print hierarchy, but then blinked.

I think we should just get rid of val_print entirely, and only have
value_print, passing around values.  If that is not efficient enough
(too much copying or something), we can change struct value to make it
efficient.

What do you think of that?

This isn't a high priority for me, either, but I suspect we'll need
another round of changes here to support DW_OP_GNU_implicit_pointer.


I did not read the patch extremely closely.  What I did read looks
reasonable.  Unfortunately the nature of a patch like this is that it is
very hard to know whether some spot was missed :-(

Tom