Re: [PATCH] detect incompatible aliases (PR c/81854)

[Joseph Myers <joseph@codesourcery.com>]

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
joseph@codesourcery.com