This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Are ifuncs intended to be allowed to resolve to symbols in another DSO?
- From: Florian Weimer <fweimer at redhat dot com>
- To: Carlos O'Donell <codonell at redhat dot com>
- Cc: Zack Weinberg <zackw at panix dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 03 Feb 2020 20:06:34 +0000
- Subject: Re: Are ifuncs intended to be allowed to resolve to symbols in another DSO?
- References: <CAKCAbMjHxyv8ymquQWatGb+7OCkUu8VtrFpiQSk3owus5g8oWw@mail.gmail.com> <87sgko4b91.fsf@oldenburg2.str.redhat.com> <559bbced-2f06-4196-719a-923e6c804e1d@redhat.com>
* Carlos O'Donell:
> If an IFUNC resolver calls a function which is not yet resolved then
> isn't that a defect in the IFUNC resolver?
There is a position that an IFUNC resolver must not use any non-local
relocations. (We must support some relocations for IFUNCs on
!PI_STATIC_AND_HIDDEN targets.) In this case, yes, such a dependencies
would be a bug because all external dependencies are bugs.
On the other hand, in glibc, we could get rid of many IFUNC resolvers
which violate this rule only after changing the loader that eliminated
their need for them. Other IFUNCs that do not follow this rule do not
have this luxury.
> The code which contains such an IFUNC should have had a DT_NEEDED entry
> on all objects to which the resolver called into?
This does not help with symbol interposition.
> I like solutions that ensure that IFUNC resolvers, which are just foreign
> functions, run at a stage *after* their own dependencies have been resolved,
> but before their own initializers have run.
Lazy binding achieves this because it implicitly tracks this dependency
information. For eager binding, we simply do not have this information.
Hence my patch for delayed relocation processing. But it does not solve
the problem completely, of course.
Thanks,
Florian