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.