On Wed, 20 Sep 2017, Martin Sebor wrote:
> 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.
I think in the case of IFUNCs defined without the attribute, a symbol
inherently has two incompatible types, one at C level and one at assembler
level. So disabling this particular warning for the combination of
(multi-arch, no IFUNC attribute) may make sense - but maybe it would be
better to enable the IFUNC attribute for all GNU/Linux targets (without
regard to whether the assembler and linker support the feature, but
arranging as needed for the assembler to give an error if support is
missing). We do *not* however want to disable any other warnings relating
to attributes.
The x32 case should be fixed by using the common ifunc macros in
make-syscalls.sh.
--
Joseph S. Myers
jos...@codesourcery.com
