On 09/20/2017 12:01 PM, Joseph Myers wrote:
On Wed, 20 Sep 2017, Martin Sebor wrote:
I'm not intimately familiar with the Glibc ifunc infrastructure
to suggest a good solution here, so assuming this works my only
idea is to suppress the warning for these builds.
Joseph, do you have a better suggestion?
Is the warning because of a declaration of memmove as aliasing
__libc_memmove being compared with the type of the __libc_memmove_ifunc
declaration (asm name __libc_memmove) rather than the __libc_memmove
declaration? If so, maybe in the non-HAVE_GCC_IFUNC case the alias should
be declared with a different type? Or should be defined inside asm in
this case (presumably with new ifunc-related macros)?
The warning is because in the declaration:
extern __typeof (__libc_memmove)
memmove __attribute__ ((alias ("__libc_memmove")));
__typeof (__libc_memmove) is the same as the type of memmove
as it should be but the type of the alias ("__libc_memmove") is
that of __libc_memmove_ifunc, presumably because of the following:
__typeof (__libc_memmove)*
__libc_memmove_ifunc (void) __asm__ ("__libc_memmove");
I think this is because the type of "__libc_memmove" in the alias
is looked up "late" after the asm above has associated its type
with __libc_memmove_ifunc.
Besides suppressing the warning using a pragma it can also be
suppressed by declaring memove with no prototype (which would
mean changing the definition of the strong_alias macro for this
kind of builds as you suggest). But this would just paper over
the type mismatch. I'm afraid I don't know enough about this
machinery to tell what might be an appropriate fix (i.e., what
would declare memove as an alias for __libc_memmove_ifunc but
with the correct type), or even if there is one.
Martin
