Re: vtable?

[Chris Moller <cmoller at redhat dot com>]

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.
>    

okay, i'll poke around in there.

> 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.
>    

hmmm...  but that doesn't explain why faking the offset--forcing 
gnuv3_baseclass_offset to return an 8 iff the type name == "D"--makes 
things work.  on yet the other hand, using a slightly more complex test 
case, which i just did, where struct A actually has something in it:

   struct A {int k; A() {k=13;};};
   struct B : virtual A {};

you get

   $1 = {<C> = {v = 13}, _vptr.D = 0x804870c}

where the 13 in 'v = 13' looks like it might have come from struct A, 
suggesting that you're right--the printing is screwed up.

thx,
chris

> Tom
>