This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] valprint.c / *-valprint.c: Don't lose `embedded_offset'
- From: Tom Tromey <tromey at redhat dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org, Joel Brobecker <brobecker at adacore dot com>
- Date: Thu, 07 Oct 2010 12:13:10 -0600
- Subject: Re: [RFA] valprint.c / *-valprint.c: Don't lose `embedded_offset'
- References: <firstname.lastname@example.org>
>>>>> "Pedro" == Pedro Alves <email@example.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> 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
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 :-(