Chris> One of my guesses of the moment is that under the circumstances of the
Chris> bug, the "vtable" is either being built wrong or is somehow being
Chris> corrupted--does anyone have a clue where the "vtable" is built?
From what I understand, gdb doesn't actually use the dwarf stuff to
build the class' vtable. There is a bug report or two in gcc bugzilla
about this; I gather that gcc doesn't emit all the needed info.
So, rather than rely on the dwarf, gdb encodes knowledge of the ABI.
Chris> Another guess is that in gnuv3_baseclass_offset, gnuv3_get_vtable is
Chris> being called with a bad type argument, but I haven't looked into that
Chris> yet.
I don't know about this code, but one interesting thing about the bug is
that casts to the base types seem to return the right answers:
(gdb) p e
$1 = (E *) 0x804a008
(gdb) p (D*)e
$2 = (D *) 0x804a00c
(gdb) p (C*)e
$3 = (C *) 0x804a010
This makes me wonder whether the bug is actually in the value printing
code -- because computing the base offsets seems to work in at least one
case.
That's just something I would look at though, don't give it too much
credence. I don't know much about this code.