This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: vtable?
- From: Tom Tromey <tromey at redhat dot com>
- To: Chris Moller <moller at nc dot rr dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Thu, 14 Jan 2010 13:10:59 -0700
- Subject: Re: vtable?
- References: <4B4F5C02.8020909@nc.rr.com>
- Reply-to: Tom Tromey <tromey at redhat dot com>
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.
Tom