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: rth at redhat dot com (Richard Henderson)
- Subject: Re: [I don't think it's off-topic at all] Linking speed for C++
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Wed, 9 May 2001 17:01:18 -0700 (PDT)
- Cc: jbuck at synopsys dot COM (Joe Buck), aj at suse dot de (Andreas Jaeger), biswapesh dot chattopadhyay at bt dot com, gcc at gcc dot gnu dot org, bastian at suse dot com
> > What will this required dynamic relocation do?
> Allow the symbol to be overridden from another DSO earlier in
> the symbol resolution search path.
OK, OK (and thanks to the other 5-6 people who told me this as well).
This feature, unfortunately, is quite expensive.
It seems the only way out that preserves the ability to override symbols,
but that gets rid of the relocations, is to have stubs for all calls.
That is, the function pointer can be replaced by
(stub_address - vtable_address)
and the stub can, in turn, be a normal PIC call (or, depending on the
details of PIC on the particular processor, just a jump). This would seem
to get rid of all the relocations for the vtable, but at a subtantial
cost. Some alternate redesign of the vtable would probably be better.
(Yes, this kind of thing will break the standard ABI).
Or, of course, just break the ability to overload symbols for virtual
functions. :-) The user waiting for his desktop to start up may not