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: Geoff Keating <geoffk at geoffk dot org>
- Date: 09 May 2001 14:21:37 -0700
- CC: gcc at gcc dot gnu dot org
- References: <200105092053.NAA20501@toledo.synopsys.com>
Joe Buck <jbuck@synopsys.COM> writes:
> 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.
> 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's no way to know, for an externally visible symbol, at link
time, which dso it is in, even if there is a definition in the same
dso as it is used, because it could be overridden elsewhere.
- Geoffrey Keating <email@example.com>