This is the mail archive of the 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++

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


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