On Sun, Jun 26, 2016 at 12:49 AM, Alexander Monakov <amona...@ispras.ru> wrote: > On Sat, 25 Jun 2016, H.J. Lu wrote: >> The resolver for ifunc functions might resolve to a non-local function. > > I think the explanation doesn't match the testcase, in which all three > functions: the resolver, the symbol being resolved, and the ultimate > resolution are all static. I don't think there was an intention to allow the > resolver reside in a different translation unit than the resolvee, so the > comment also seems confusing if not wrong.
Normally the actual function is in a different file: --- /* Redefine strstr so that the compiler won't complain about the type mismatch with the IFUNC selector in strong_alias, below. */ #undef strstr #define strstr __redirect_strstr #include <string.h> #undef strstr #define STRSTR __strstr_sse2 #ifdef SHARED # undef libc_hidden_builtin_def # define libc_hidden_builtin_def(name) \ __hidden_ver1 (__strstr_sse2, __GI_strstr, __strstr_sse2); #endif #include "string/strstr.c" extern __typeof (__redirect_strstr) __strstr_sse2_unaligned attribute_hidden; extern __typeof (__redirect_strstr) __strstr_sse2 attribute_hidden; #include "init-arch.h" /* Avoid DWARF definition DIE on ifunc symbol so that GDB can handle ifunc symbol properly. */ extern __typeof (__redirect_strstr) __libc_strstr; libc_ifunc (__libc_strstr, HAS_ARCH_FEATURE (Fast_Unaligned_Load) ? __strstr_sse2_unaligned : __strstr_sse2) #undef strstr strong_alias (__libc_strstr, strstr) ---- -- H.J.