ifunc resolving

[Florian Weimer]

* Zack Weinberg:

> On Wed, Jan 20, 2021 at 4:33 AM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>> * Alan Modra via Libc-alpha:
>> > On Tue, Jan 19, 2021 at 03:59:54PM +0100, Florian Weimer via Binutils wrote:
>> > 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.
>
> Every time this discussion comes up, I wonder how much it would help
> if we completely scrapped the idea of lazy relocations.  Do what
> LD_BIND_NOW=t does all the time.  Distributions are moving in this
> direction already because that lets them turn on -z relro...

Lazy relocations make this much easier (if they can in fact be used).
Some tcmalloc versions called getenv from an IFUNC resolver and it
actually worked.  BIND_NOW broke it.

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