https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70082
--- Comment #4 from Carlos O'Donell <carlos at redhat dot com> --- (In reply to Jakub Jelinek from comment #3) > I don't think the compiler should do the policeman here, it is enough if > glibc documents what it does and doesn't support in ifunc (which is of > course generally arch dependent, it really depends on if you need e.g. > RELATIVE relocations relocated in the current library/binary already, or if > you need other data relocations, etc. E.g. calling hidden function or even > non-hidden, as long as you hide it in symbol version script, is fine. > Calling function from other library very likely not. The compiler is already a policeperson :-) The compiler enforces language standards. The compiler enforces that ifunc attribute functions can't be declared weak or weakref. Why not enforce the rest of the safe behaviour of the IFUNC extension? Is it hard to enforce the rest of the requirements? Are we worried that because we haven't enforced these rules over the last 6 years (typo, the implementation was added in 2010 not 2005 for IFUNC attribute usage) that people are using attribute ifunc with all their caveats in ways which we will now restrict? I don't particularly see how this is any different from tightening a language standard. However, I agree it's a concern. Packages are only just starting to use IFUNC, and we should improve what we have at both the documentation and implementation level. Filed this glibc bug to bring i386 and x86_64 up the level of all the other arches: "Bug 19766 - All machines should pass dl_hwcap to ifunc resolvers." https://sourceware.org/bugzilla/show_bug.cgi?id=19766 With bug 19766 fixed the x86_64 ifunc resolvers should be able to do something safely (though it will require a gcc change to generate the dep on a glibc version to ensure it works without error).
