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.

Reply via email to