https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81193
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amodra at gmail dot com
--- Comment #3 from Alan Modra <amodra at gmail dot com> ---
Relocation problems with ifunc resolvers come about due to the fact that ifunc
resolvers run at the same time other relocations are being processed.
So..
1) If the resolver runs before its code/data has been relocated, the resolver
won't run correctly.
2) If the object requires text relocations then the text segment will be set
read/write, but this makes it non-exec so any attempt to run an ifunc resolver
will result in a segfault.
(1) is fixed for leaf function resolvers called from within the same object
(shared lib or executable), as the linker sorts ifunc relocs last. You will
need to know the order in which an executable and its shared libraries are
relocated by ld.so if you want to call a non-local resolver, or when the
resolver itself makes non-local calls to functions that need their code/data
relocating. Generally, don't do that. By inspection, getauxval loads values
from the TOC/GOT, so it does need relocating, but if ld.so always relocates
libc.so first then you might be OK calling getauxval.. I don't know enough
about ld.so to answer that detail. And, oh yeah, provided the user doesn't
override libc.so getauxval with their own version.
(2) will give you an error/warning at link time.
