ia64 vtable entries (was: C implementations of the C++ ABI)

[Cary Coutant]

>I think it's unreasonable.  If we want this kind of relocation
>we should invent a new relocation type.  Which I don't necessarily
>think is unreasonable, but a pure pic solution without any runtime
>relocation requirement might be better.
>
>IPLT just has too many other semantics.
>
>What exactly are you going to do when IPLT appears in a relocatable
>object, referencing a dynamic symbol, and so needs to be copied into
>the dso?  How are you going to differentiate that from an IPLT reloc
>that is associated with the .IA_64.pltoff array? 

The IPLT relocations have *exactly* the right semantics. It's just like 
the DIR relocations, which, when used in a relocatable object, pass 
through to the shared object as dynamic relocations -- the relocation has 
the same meaning, but it can only be applied at load time. 

The IPLT relocations were designed (it's not "sheer luck," as Christophe 
put it) to support the relocation of a function descriptor, and that's 
exactly what you need to relocate a function descriptor in the vtable. If 
you see it in a relocatable object, you have to pass the relocation 
through to the shared object, so the descriptor can be relocated at load 
time.

There are no other semantics associated with the IPLT relocations. You 
might be reading more into the description than is intended: when it 
refers to initializing it with a copy of the official function 
descriptor, that's analogous to a DIR relocation initializing the target 
with a copy of the address of the referenced symbol. All it really means 
is that the first doubleword should point to the function's entry point, 
and the second doubleword should contain the appropriate gp value.

-cary