[PATCH] D15235: [ELF] - Implemented R_*_IRELATIVE relocations for x86, x64 targets.

[Joerg Sonnenberger via llvm-commits]

On Thu, Dec 10, 2015 at 12:39:46AM -0800, George Rimar via llvm-commits wrote:
> >On Tue, Dec 08, 2015 at 06:21:07PM +0000, Rui Ueyama via llvm-commits wrote:
> >> ruiu added a comment.
> >>
> >> I'm not still sure if these relocations have to be handled by the linker. These relocations use runtime addresses, so only the dynamic linker has to handle them, no?
> >
> >We should have at least some story for static linking. IIRC glibc
> >doesn't support it for that, but if I ever want to exploit them for
> >NetBSD, consistent behavior for static binaries certainly is a
> >must-have. It could transform it to a stub function that does an
> >indirect call.
> >
> >Joerg
> 
> Thats sounds like separate specific feature. But in my opinion it opposes to core idea of GNU_IFUNC which was fast dispatching.
> If I correctly undertand the idea of stub: it will call ifunc method to get the address of destination function and then call it, that will happen for each call.
> Idea of ifunc was to resolve all of that that during the first call or even during app start. So such change will bring some slowdown.
> Best solution I think would be to update dynamic linker to support the ifunc.

There is no dynamic linker for statically linked binaries. That's the
very idea of static linking. The stub should do a plain indirect jump.
The first call goes to an internal resolver, which calls the ifunc
method, updates the binding address and calls the real function as tail
call. I'm fine with that internal resolver having to be provided by libc
or whatever. This is potentially a bit slower than ifunc in the dynamic
case, if the PLT is writeable and doesn't use indirect jumps. But that's
still better than the current failure mode of not being supported at
all. Having to do runtime redirection completely different for slightly
different link modes sucks.

Joerg