help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

g++ object model for vfts


From: Dan
Subject: g++ object model for vfts
Date: Wed, 05 Sep 2007 16:04:43 -0000
User-agent: G2/1.0

Hi,

I'm trying to understand g++'s object model, and specifically how it
uses it virtual function tables. I guess I start with the "dumb"
question, which is: is there a reference (in the vein of the ARM book)
for how these structures are implemented in g++?

My specific question is taken from looking at the assembly output from
Xalan (xalancbmk, spec2006, specific detail included at the end of the
post).

This is the no-arg constructor for XercesParserLiaison:
(xalanc_1_8::XercesParserLiaison::XercesParserLiaison())

.globl _ZN10xalanc_1_819XercesParserLiaisonC2Ev
        .type   _ZN10xalanc_1_819XercesParserLiaisonC2Ev, @function
_ZN10xalanc_1_819XercesParserLiaisonC2Ev:
.LFB3547:
        pushl   %ebp
.LCFI8:
        movl    %esp, %ebp
.LCFI9:
        pushl   %ebx
.LCFI10:
        subl    $20, %esp
.LCFI11:
        movl    8(%ebp), %eax
        movl    %eax, (%esp)
.LEHB10:
        call    _ZN10xalanc_1_816XMLParserLiaisonC2Ev
.LEHE10:
        movl    8(%ebp), %eax
        addl    $4, %eax
        movl    %eax, (%esp)
        call    _ZN11xercesc_2_512ErrorHandlerC2Ev
        movl    8(%ebp), %eax
        movl    $_ZTVN10xalanc_1_819XercesParserLiaisonE+8, (%eax)
        movl    8(%ebp), %eax
        addl    $4, %eax
        movl    $_ZTVN10xalanc_1_819XercesParserLiaisonE+152, (%eax)
        movl    8(%ebp), %eax
        movl    $-1, 8(%eax)
; . . .

I think I understand the instruction that moves
_ZTVN10xalanc_1_819XercesParserLiaisonE+8 (loading the vft into the
datastructure, skipping the first 8 bytes (the first 4 seem to always
be 0 in the vfts anyway)),
but the next word in the datastructure gets the vft+152. Looking at
the vft, the symbol there is _ZTIN10xalanc_1_819XercesParserLiaisonE,
which c++filt describes as "typeinfo for
xalanc_1_8::XercesParserLiaison" Is this RTTI stuff? if so, why is it
stored in the virtual function table? (And is there a way to
differentiate between virtual function and type info in the table?)

Thanks,

-Dan

Addendum:
Compilation details: x86 (obviously), Debian, g++ version 3.3.5. The
output from g++ -v on my box is:
dww4s@p4-2c-11 xalancbmk $ g++ -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v --enable-languages=c,c+
+,java,f77,pascal,objc,ada,treelang --prefix=/usr --mandir=/usr/share/
man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/
3.3 --enable-shared --enable-__cxa_atexit --with-system-zlib --enable-
nls --without-included-gettext --enable-clocale=gnu --enable-debug --
enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-
linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-13)

The example (XMLParserLiaison.c) was compiled without optimization.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]