This is the mail archive of the
mailing list for the GCC project.
Re: [I don't think it's off-topic at all] Linking speed for C++
- To: Joe Buck <jbuck at synopsys dot COM>
- Subject: Re: [I don't think it's off-topic at all] Linking speed for C++
- From: Jeff Sturm <jsturm at one-point dot com>
- Date: Wed, 9 May 2001 17:58:01 -0400 (EDT)
- cc: gcc at gcc dot gnu dot org
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
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