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: Richard Henderson <rth at redhat dot com>
- Date: Wed, 9 May 2001 11:45:15 -0700
- Cc: Andreas Jaeger <aj at suse dot de>, biswapesh dot chattopadhyay at bt dot com, gcc at gcc dot gnu dot org, bastian at suse dot com
- References: <20010509110912.A26569@redhat.com> <200105091839.LAA16816@toledo.synopsys.com>
On Wed, May 09, 2001 at 11:39:04AM -0700, Joe Buck wrote:
> Clearly, if the pointer points to a global symbol that is defined
> externally, we we still need a relocation. But it will be common to refer
> to a function whose definition comes from the same object file, or the
> same .so (meaning that relocations can be eliminated when building the
> shared library).
No, you misunderstand. If the symbol is _visible_ externally, then a
dynamic relocation is required. Even if the actual definition comes
from the current dso. This is just the way ELF dynamic linking works.
> So it seems to me that at least some (though not all) relocations can be
> made to disappear on all platforms.
If you can't get rid of them all, then you can't make them read-only.
> This would require an extra instruction on the sparc but not the x86
> (though there could still be a penalty on the x86 because use of the
> ALU affects ILP).
Yes. Oh well. Whaddaya want, something for nothing? ;-)