This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: IFUNC resolver scheduling (bugs 21041, 20019)
On 01/28/2017 03:27 AM, Carlos O'Donell wrote:
On 01/25/2017 08:57 AM, Florian Weimer wrote:
I tried to fix most of the issues involving IFUNC resolvers and their access to unrelocated symbols.
...
Comments?
H.J.'s patch turns a runtime segfault (if the function is ever
called)
This all about non-lazy binding, so whether the function is called, does
not matter. (Even with lazy binding enabled, there are some relocations
for which lazy binding is not available, so the issue can still happen
with lazy binding.)
into a dynamic loader failure message that tells you
exactly what is wrong.
I do not think this is an accurate characterization of the impact of the
change. The breakage it detects cannot always be fixed by relinking.
We need to decide whether IFUNC resolvers can use relocations. If yes,
we need something to reorder the relocation processing in a more useful
way. The restrictions in H.J.'s patch will no longer be necessary as a
result.
If no (which is what is currently implied by the wiki page), we need to
revert H.J.'s patch because the execution order of IFUNC resolvers with
regard to other relocations does not matter. But in this case, we need
to fix glibc to comply with the rules. I don't see how this is possible
without chaning the (architecture-specific) IFUNC resolver function
argument lists (to be able to access architecture-specific information
without relying on relocations), so it is a somewhat invasive change.
The segfault scenario has been present since Feb 2015, and thus
possibly 4 releases.
I think it has been there for much longer than that. Increased use of
BIND_NOW just uncovered more problems.
Revering H.J.'s patch just gets us back to things crashing
mysteriously at runtime. So I'm not looking to revert the patch.
It also un-breaks programs which comply with the wiki rules on IFUNC
resolvers.
The only alternative seems to be to loosen the soname and
version checks and remove the versioned interposers from
libpthread? That seems more risky than your change.
I think the soname check only ensures that there is any matching version
with the soname for the symbol. Curiously, the versioned symbol can
still be bound to a definition in any DSO, irrespective of the soname.
There is only one definition for a symbol/version pair, the soname is
*not* used as a tie-breaker.
Luckily for us, this should make it fairly safe to drop the soname check
because it does not alter symbol binding. More programs will work as a
result, and we could drop the problematic IFUNC-based redirections in
libpthread (which is a prerequisite for complying with the wiki IFUNC
resolver requirements).
(We should also fix the static linker to disregard compat symbols more
effectively; we shouldn't have bindings to compat functions in
libpthread at all.)
Do you think your patch is viable for 2.25 to fix bug 21041?
We don't have a complete patch yet, and I still don't see consensus
whether we actually want to relax the documented IFUNC resolver
requirements. I'm not even sure which direction you prefer. :) (And I
haven't made up my mind, either.)
What's worse, the patch changes the architecture-specific parts of the
dynamic linker and thus (partially) invalidates the release testing done
os far.
Thanks,
Florian