Removing longjmp error handling from the dynamic loader
Florian Weimer
fweimer@redhat.com
Mon Mar 11 18:49:00 GMT 2019
* Zack Weinberg:
>> Rich Felker brought up this matter in conjunction with IFUNC resolvers.
>> These can be called during relocation processing (from dlopen) or lazy
>> binding, when they themselves trigger lazy binding. I think these
>> errors should not be recoverable, either, whether they happen during
>> relocation processing or lazy binding. But there is a narrow edge case
>> (IFUNC resolver called during relocation processing which triggers lazy
>> binding which fails in symbol lookup)
>
> I wonder how practical it would be to discover the set of symbols that
> an IFUNC resolver might attempt to use, and resolve those before
> calling into the IFUNC resolver. IFUNCs are still new enough that we
> could require additional annotations in the object file if that would
> help.
Considering that the whole purpose of IFUNC resolvers is to select
implementations, eagerly resolving all potentially needed relocations
(even without BIND_NOW) seems rather excessive and not very
backwards-compatible.
I've proposed two-phase relocation processing before, first all
non-IFUNC relocations, followed by the IFUNC relocations that have been
queued. A two-phase approach is needed for most cases involving IFUNCs,
non-lazy binding, and symbol interposition. It does not solve all IFUNC
issues (you cannot in general, if there is a circular depenedency for
example), but I think it would be a good addition, and it would even fix
some glibc bugs where we use IFUNC resolvers improperly. It applies to
the BIND_NOW case only, which, like you, I consider the more relevant
one.
Thanks,
Florian
More information about the Libc-alpha
mailing list