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

[Martin Sebor]

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