This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [I don't think it's off-topic at all] Linking speed for C++
- To: rth at redhat dot com (Richard Henderson)
- Subject: Re: [I don't think it's off-topic at all] Linking speed for C++
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Wed, 9 May 2001 14:03:54 -0700 (PDT)
- Cc: bastian at kde dot org (Waldo Bastian), jbuck at synopsys dot COM (Joe Buck), aj at suse dot de (Andreas Jaeger), biswapesh dot chattopadhyay at bt dot com, gcc at gcc dot gnu dot org, bastian at suse dot com
> The problem on x86 is that the PIC PLT entry requires that
> %ebx already be set up properly _for that dso_. Which means
> that you can't the PLT entry for a different dso, which is
> what you'd be doing if you put the address of the PLT entry
> in the vtable.
>
> It would be possible to generate stub functions along with
> the vtable instead. I've not got a clear idea what that
> would do to program size and performance.
This approach would mean that if we have class Base in one dso and class
Derived : public Base in another, for each virtual method func of Base
that is not overriden in class Derived, we'd add a stub Derived::func that
would belong to the same dso as Derived, and would do a direct PIC call to
Base::func.
If this were done, then it seems we can now have purely relocatable
vtables using the offset method: every offset is between a function
defined in the current dso and a vtable also defined in the current
dso. The penalty is an extra call and an extra stub function, though
these stubs will be very small.
The size penalty of the stubs would be traded off against the size
improvement because the vtables can now be shared. The number of
stubs needed will depend on shared library organization but could be
large if there are many dsos that use the same C++ classes.
Since we can do the extra addition in the virtual function call for
free in most cases on the x86, it seems that this could be a win for
the KDE folks.