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

[Joe Buck <jbuck at synopsys dot COM>]

I wrote:
> > Or, of course, just break the ability to overload symbols for virtual
> > functions. :-)  The user waiting for his desktop to start up may not
> > care.

Richard Henderson writes:
> Recently some symbol visibility flags were added to ELF.  It
> would be possible to change the compiler such that
> 
>   class __attribute__((visibility(protected))) Foo
>   {
>   ...
>   };
> 
> marked each member symbol of Foo with STV_PROTECTED, which
> prevents this symbol from being overridden by another DSO.

OK, I'll flesh out my original proposal.  We add two attributes,
which I will temporarily call vtable_pic and vtable_stubs until
I think of better names.

The vtable_pic attribute may be applied to a base class (that is, a class
that is not derived from another class).  If present, the vtable is
generated in offset form (function address minus vtable address);
furthermore, the above mentioned attribute, visibility(protected), is
applied to all virtual member functions of the current class and any
derived class.  Multiple inheritance from a vtable_pic class is only
allowed if all base classes that have virtual functions define vtable_pic,
so the compiler always knows how to generate virtual function calls.

The vtable_stubs attribute may be applied to a derived class,
provided that some base class has the vtable_pic attribute.  This
attribute is intended for use when the definitions of the member
functions of the derived class are in a different dso than the
functions of the base class.  What it does is to create a small
stub function for each member function of the base class that is
not overridden in the derived class.  The effect is as if we had
virtual function definitions of the form

// sloppy pseudocode
returntype Derived::method(arglist)
{
	return Base::method(arglist);
}

for all non-overriden functions.  Further-derived classes would have
their vtable entries pointing to the stub function, not the original.

By applying these two attributes correctly, the library designer can wind
up with completely PIC virtual function tables, requiring no relocations
at all.  The vtables can be placed in the text section.

The price is an extra addition in a virtual function call
(which will be free in most cases on x86), plus extra stub functions
for classes defined in one dso that are derived from classes defined
in another dso.

Exception handling is also non-PIC; sorry, I don't know enough about
the current implementation to have any suggestions for reducing the
number of relocations.  Maybe Mike Stump has ideas.  In any case,
the KDE folks already use -fno-exceptions for this reason.