This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [I don't think it's off-topic at all] Linking speed for C++



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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]