Re: PowerPC STT_GNU_IFUNC support

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Wed, Jul 22, 2009 at 4:16 PM, Alan Modra<amodra@bigpond.net.au> wrote:
> On Tue, Jul 14, 2009 at 08:31:59PM +0000, Joseph S. Myers wrote:
>> On Fri, 10 Jul 2009, Alan Modra wrote:
>>
>> > include/elf/
>> > ? ? * ppc.h (R_PPC_IRELATIVE): Add.
>> > ? ? (R_PPC_RELAX32, R_PPC_RELAX32PC,
>> > ? ? R_PPC_RELAX32_PLT, R_PPC_RELAX32PC_PLT): Renumber.
>> > ? ? * ppc64.h (R_PPC64_IRELATIVE): Add.
>>
>> Do you have specifications for the new relocations? ?They'll need to be
>> looked at by the Power.org ABI working group, whether for the present
>> revision or a future revision. ?(We're thinking of working on the 64-bit
>> ABI once the 32-bit ABI revision is finished, though the 64-bit ABI needs
>> a lot less work done to it.)
>
> I probably should have written a spec before I started, and I may have
> realised that PowerPC needs two new relocations. ?On PLT entries we
> need a relocation that behaves like R_PPC_JMP_SLOT, while for GOT
> entries we need one that behaves like R_PPC_RELATIVE. ?For the new
> secureplt ABI, the PLT is really just another GOT. ?Unsurprisingly,
> R_PPC_JMP_SLOT behaves just like GOT relocs there. ?However, for the
> old ABI, R_PPC_JMP_SLOT does a whole lot of work, creating various
> branches and other data. ?It's rather too messy to expect one new
> relocation to handle both situations.
>
> PowerPC64 similarly needs two new relocations. ?In the PLT, one new
> reloc needs to copy a 24 byte OPD entry, while in the GOT the other
> new reloc just writes an 8 byte word.
>

Can you just use R_PPC_IRELATIVE? I was thinking to add a new
JMP_SLOT relocation for x86. But it turned out not necessary. Those
threads:

http://sourceware.org/ml/libc-alpha/2009-05/msg00164.html
http://sourceware.org/ml/libc-alpha/2009-06/msg00008.html

may give you some ideas. Basically, linker has to turn ALL
calls to the ifunc functions to its PLT entry.

I am enclosing some notes of mine. Hope they may help.


-- 
H.J.
---
All references to a STT_GNU_IFUNC symbol, including function call and
function pointer, will go through a PLT slot, which jumps to the address
stored in the GOT entry.  If the STT_GNU_IFUNC symbol is locally defined,
a R_*_IRELATIVE relocation will be applied to the GOT entry at load time.
Otherwise, dynamic linker will lookup the symbol at the first call to the
function and update the GOT entry. This applies to all usages of
STT_GNU_IFUNC symbols in shared library, dynamic executable and static
executable.

The calling convention of the STT_GNU_IFUNC function, which takes no
arguments and returns a function pointer, should follow the
processor-specific ABI. All rules for caller-saved and callee-saved
registers apply.

Note:

Instead of branching to an STT_GNU_IFUNC symbol directly, we always
branch to its PLT entry, which simply loads its GOTPLT entry and branch
to it.  Its GOTPLT entry has the real function address.  It has an
optional GOT entry for the function pointer value of the symbol.  To
load an STT_GNU_IFUNC symbol function pointer value,

1. Use its GOTPLT entry in a shared object if it is forced local or not
dynamic.
2. Use its GOTPLT entry in a non-shared object if pointer equality isn't
needed.
3. Use its GOTPLT entry in a position independent executable (PIE).
4. Use its GOTPLT entry if no normal GOT, other than GOTPLT, is used.
5. Otherwise use its GOT entry.  We only need to relocate its GOT entry
in a shared object.

We need dynamic relocation for STT_GNU_IFUNC symbol only when there is a
non-GOT reference in a shared object.

When a shared library references a STT_GNU_IFUNC symbol defined in
executable, the address of the resolved function may be used.  But in
non-shared executable, the address of its GOTPLT entry may be used.
Pointer equality may not work correctly.  PIE should be used if pointer
equality is required here.