This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

>>>>> "Pedro" == Pedro Alves <> 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

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 :-(


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]