Re: [I don't think it's off-topic at all] Linking speed for C++

[Joe Buck <jbuck at synopsys dot COM>]

> On Wed, May 09, 2001 at 09:19:59AM -0700, Joe Buck wrote:
> > If pic_vtable is specified, the function pointers in the virtual function
> > table would be replaced by (pointer - vtable_address).  This means that
> > they would now be PIC.
> 
> No it doesn't.  If pointer references a globaly visible symbol,
> then the vtable is _still_ subject to dynamic relocation.

You are far more expert on these matters than I am.  Still:

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).  In this case, if we put the vtable in the text section,
pointer - vtable_address is simply a constant, on any platform.  This
would be true for some vtable entries but not others (in some cases, a
separate .so would define a class that is derived from a class whose
implementation is in another .so).

So it seems to me that at least some (though not all) relocations can be
made to disappear on all platforms.

> What you need is a pc-relative relocation to a PLT entry.  Few
> targets support this kind of relocation.  Though x86 and Sparc
> do, so it's not entirely without merit.
> 
> > 	register1 <- *(register0)		
> > 	register2 <- *(offset + register1) + register1
> > 	call *register2
> 
> You'd wind up with
> 
> 	r1 = *r0
> 	r2 = r1 + offset
> 	r3 = *r2 + r2
> 	call *r3
> 
> with the relocations that are available on x86 and sparc.

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).