* vtable?
@ 2010-01-14 18:01 Chris Moller
2010-01-14 20:11 ` vtable? Tom Tromey
0 siblings, 1 reply; 6+ messages in thread
From: Chris Moller @ 2010-01-14 18:01 UTC (permalink / raw)
To: Project Archer
I'm hacking on bz 9629 "GDB fails to display the base class through the
derived class if the derived class contains more than one vptr for
virtual function." http://sourceware.org/bugzilla/show_bug.cgi?id=9629
One of my guesses of the moment is that under the circumstances of the
bug, the "vtable" is either being built wrong or is somehow being
corrupted--does anyone have a clue where the "vtable" is built? I'd've
thought in dwarf2read.c, but if it's there it's not obvious (at least to
me...).
Another guess is that in gnuv3_baseclass_offset, gnuv3_get_vtable is
being called with a bad type argument, but I haven't looked into that yet.
Thanks,
Chris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vtable?
2010-01-14 18:01 vtable? Chris Moller
@ 2010-01-14 20:11 ` Tom Tromey
2010-01-14 20:30 ` vtable? Chris Moller
2010-01-19 16:15 ` vtable? Chris Moller
0 siblings, 2 replies; 6+ messages in thread
From: Tom Tromey @ 2010-01-14 20:11 UTC (permalink / raw)
To: Chris Moller; +Cc: Project Archer
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vtable?
2010-01-14 20:11 ` vtable? Tom Tromey
@ 2010-01-14 20:30 ` Chris Moller
2010-01-19 16:15 ` vtable? Chris Moller
1 sibling, 0 replies; 6+ messages in thread
From: Chris Moller @ 2010-01-14 20:30 UTC (permalink / raw)
To: archer
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vtable?
2010-01-14 20:11 ` vtable? Tom Tromey
2010-01-14 20:30 ` vtable? Chris Moller
@ 2010-01-19 16:15 ` Chris Moller
2010-01-19 22:33 ` vtable? Tom Tromey
1 sibling, 1 reply; 6+ messages in thread
From: Chris Moller @ 2010-01-19 16:15 UTC (permalink / raw)
To: Tom Tromey; +Cc: Project Archer
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.
Chris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vtable?
2010-01-19 16:15 ` vtable? Chris Moller
@ 2010-01-19 22:33 ` Tom Tromey
2010-01-20 8:44 ` vtable? Chris Moller
0 siblings, 1 reply; 6+ messages in thread
From: Tom Tromey @ 2010-01-19 22:33 UTC (permalink / raw)
To: Chris Moller; +Cc: Project Archer
>>>>> "Chris" == Chris Moller <cmoller@redhat.com> writes:
Chris> So the question is whether the right thing to do is fix the gdb a
Chris> priori information hack, or to fix gcc (if necessary--a DWARF dump of
Chris> the testcase shows a lot of information concerning all of the relevant
Chris> classes, but whether it's right or sufficient I don't know) and fix
Chris> gdb properly to use the DWARF info.
Fix gdb's current approach. The ABI is pretty stable, and gdb already
uses it for a lot of things.
Tom
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: vtable?
2010-01-19 22:33 ` vtable? Tom Tromey
@ 2010-01-20 8:44 ` Chris Moller
0 siblings, 0 replies; 6+ messages in thread
From: Chris Moller @ 2010-01-20 8:44 UTC (permalink / raw)
To: Tom Tromey; +Cc: Project Archer
On 01/19/10 17:32, Tom Tromey wrote:
>>>>>> "Chris" == Chris Moller<cmoller@redhat.com> writes:
>>>>>>
>
> Chris> So the question is whether the right thing to do is fix the gdb a
> Chris> priori information hack, or to fix gcc (if necessary--a DWARF dump of
> Chris> the testcase shows a lot of information concerning all of the relevant
> Chris> classes, but whether it's right or sufficient I don't know) and fix
> Chris> gdb properly to use the DWARF info.
>
> Fix gdb's current approach.
Okay, will do.
cm
> The ABI is pretty stable, and gdb already
> uses it for a lot of things.
>
> Tom
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-01-20 8:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-01-14 18:01 vtable? Chris Moller
2010-01-14 20:11 ` vtable? Tom Tromey
2010-01-14 20:30 ` vtable? Chris Moller
2010-01-19 16:15 ` vtable? Chris Moller
2010-01-19 22:33 ` vtable? Tom Tromey
2010-01-20 8:44 ` vtable? Chris Moller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).