rtld: resolve incoming STT_GNU_IFUNC only after DT_INIT

[John Reiser]

On 11/01/2017 1635Z, Florian Weimer wrote:
> * John Reiser:
> 
>> When loading a shared library, either DT_NEEDED or via dlopen(),
>> then the processing by rtld of relocations in other modules which
>> refer to STT_GNU_IFUNC symbols in the current library causes
>> problems for me.  Relocating a reference from outside to a
>> STT_GNU_IFUNC symbol causes the IFUNC code to be called before the
>> DT_INIT executes.  This is not nice.
> 
> But this is required because the DT_INIT code may need IFUNC-backed
> relocations.  And there is no way to tell which relocations are needed
> for DT_INIT and which are just required afterwards.

My understanding is that IFUNC-backed relocations to symbols in the same
module have been converted by the static binder /bin/ld into R_*_IRELATIVE
relocations which refer directly to the address and not to any symbol.
[This is the behavior that I see in current /bin/ld for 32-bit ARM, for example.]
The compressor sees these relocations, and hides them from rtld
(move them to the high end of the list [usually they are already
at the high end in order to avoid dependency problems], decrement the
stated size, but keep them and remember that they are there.)
The de-compressor processes the hidden relocations specially,
immediately after decompressing the instructions, and before
resuming any other execution.

However, a relocation from some other module to a STT_GNU_IFUNC symbol
in the current shared library cannot be intercepted like that.
That's why DT_INIT should be called before such a relocation is resolved,
so that the IFUNC code can be de-compressed into the right place
before it gets called.

> 
>> It seems to me that rtld could change the order of evaluation, so that
>> DT_INIT is called before any other code in the library is executed,
>> including the code for resolving incoming references to STT_GNU_IFUNC
>> symbols in the library.  Comments?
> 
> I don't think this is possible at all.
> 

I still think it's possible.

--