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