This is the mail archive of the
mailing list for the Archer project.
On 01/14/10 15:10, Tom Tromey wrote:
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.
What appears to be happening is that when you try to print the base
class [p *(D*)e], build_gdb_vtable_type in gnu-v3-abi.c gets called to
set up a top-level type struct containing, among other stuff, a field
tagged "vcall_and_vbase_offsets" that, so far as I can tell, contains
nothing useful--i.e., it's empty. Later, in gnuv3_baseclass_offset,
when the vtable is accessed for that field, it still appears to be
empty. In fact, it hasn't been touched at all--the numeric values of
the pointers, and all the other fields, are the same as they where when
initialised. If gdb is supposed to be using knowledge of the ABI to
build that field, it isn't.
So the question is whether the right thing to do is fix the gdb a priori
information hack, or to fix gcc (if necessary--a DWARF dump of the
testcase shows a lot of information concerning all of the relevant
classes, but whether it's right or sufficient I don't know) and fix gdb
properly to use the DWARF info.