Re: ifunc resolving

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* Alan Modra via Libc-alpha:

> On Tue, Jan 19, 2021 at 03:59:54PM +0100, Florian Weimer via Binutils wrote:
>> We have two positions that still need to be reconciled:
>> 
>> * IFUNC resolvers must not themselves have relocation dependencies
>>   because they can be called at any time during relocation.  This
>>   restricts the functionality available to an IFUNC resolver.
>
> On many architectures this cannot be achieved without hand-crafted
> assembly.  The reason is obvious.  Ifunc resolvers return an address.
> Compilers load addresses from the GOT, particularly for PIC.  GOT
> entries need relocation.

Yes, this works best for what glibc considers PI_STATIC_AND_HIDDEN
architectures.
>
>> * IFUNC resolvers may have relocation dependencies, but they may only be
>>   called after the object that contains them has been relocated.  This
>>   restricts how IFUNC symbols can be used (interposition is limited,
>>   correct dependency ordering via DT_NEEDED is required).
>
> No interposition in practice, because the object doing the interposing
> is almost always relocated later.

Right, and that was hard for glibc.

>> I do not think we have ever achieved consensus which position is the
>> correct one.
>
> There is a third possibility.  If ld.so defers all irelative and other
> relocations using ifunc symbols until all non-ifunc relocations have
> been performed, globally, then ifunc resolvers would only have the
> restriction that they not call other ifuncs.
>
> That idea was floated a very long time ago.  For some reason it is
> too hard or too slow to do in ld.so.

It's not too hard, I wrote a patch.  I didn't mention it because it was
rejected.  It seemed about the only thing for which we had consensus. 8-/

My patch did not find an appropriate order in all cases.  I think that's
more or less unavoidable if IFUNC resolvers depend on relocations
against other IFUNC resolvers.  It would have nicely covered all
internal glibc uses at the time.

> If it's too hard for glibc itself, it's too hard for anyone to use
> anywhere.

Agreed, it's difficult to argue against that.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill