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

[Jeff Sturm <jsturm at one-point dot com>]

On Wed, 9 May 2001, Joe Buck wrote:
> It seems that this should be fixable by making the linker smarter.  After
> all, for the case of an offset to the same dso, what we have is a
> constant.  What will this required dynamic relocation do?  There is
> nothing to relocate, nothing to compute!  When we do gcc -shared, we wind
> up with an .so that has some relocation expressions in which the
> relocations cancel.  Why can't they be constant-folded, so when this .so
> is linked to at runtime, no relocation is left?

As I understand it (and I am not an expert), the ELF dynamic linker
searches the list of dso's to resolve a global symbol.  So there is no
constant offset known at link-time (unless you link with -Bsymbolic, and
I'm not quite sure just what that does).  This is the way ELF works.  Any
global symbol can be overridden in another shared object, to provide for
backlinking.

There was a recent thread on the gcj list on this very topic.  The gcj
runtime, libgcj.so, currently has about 75,000 relocations on GNU/Linux.
As the java language is not C++, there may be some alternatives for
gcj such as preparing vtables at runtime.

For C++ I'm not sure what you can do, especially in the constraints of an
ABI.  Perhaps the vtable entries could initially point to a private
function that would lazily find the appropriate method and write the
address to the vtable slot?  I have no idea if that would be of any
benefit.

Jeff