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

[Martin Sebor <msebor at gmail dot com>]

On 09/20/2017 10:38 AM, Steve Ellcey wrote:
> On Wed, 2017-09-20 at 10:17 -0600, Martin Sebor wrote:
> > The comment copied below from sysdeps/aarch64/multiarch/memmove.c
> > suggests this might be deliberate:
> >
> > /* Redefine memmove so that the compiler won't complain about the
> > type
> >     mismatch with the IFUNC selector in strong_alias, below.  */
> >
> > so my guess is that the improved type checking has just exposed
> > this mismatch.  Can you please post the translation unit so we
> > can confirm it?
> >
> > Thanks
> > Martin
>
> The translation unit is sysdeps/aarch64/multiarch/memmove.c.  If I
> preprocess that and cut out the unneeded parts I get:
>
> extern int i;
> typedef long unsigned int size_t;
> extern void *__redirect_memmove (void *__dest, const void *__src,
> size_t __n)
>      __attribute__ ((__nothrow__ )) ;
> extern __typeof (__redirect_memmove) __libc_memmove;
> extern __typeof (__redirect_memmove) __memmove_generic ;
> extern __typeof (__redirect_memmove) __memmove_thunderx ;
> extern __typeof (__libc_memmove) __libc_memmove;
> __typeof (__libc_memmove) *__libc_memmove_ifunc (void) __asm__
> ("__libc_memmove");
> __attribute__ ((__optimize__ ("-fno-stack-protector"))) __typeof
> (__libc_memmove) *__libc_memmove_ifunc (void)
>         {
>                 __typeof (__libc_memmove) *res = i ? __memmove_thunderx
> : __memmove_generic; return res; }
>
> __asm__ (".type " "__libc_memmove" ", %gnu_indirect_function");
> extern __typeof (__libc_memmove) memmove __attribute__ ((alias
> ("__libc_memmove")));;
>
>
> Which, when compiled gives me:
>
>
> % install/bin/gcc -c x.c
> x.c:15:34: warning: ‘memmove’ alias between functions of incompatible
> types ‘void *(void *, const void *, size_t) {aka void *(void *, const
> void *, long unsigned int)}’ and ‘void * (*(void))(void *, const void
> *, size_t) {aka void * (*(void))(void *, const void *, long unsigned
> int)}’ [-Wattributes]
>  extern __typeof (__libc_memmove) memmove __attribute__ ((alias
> ("__libc_memmove")));;
>                                   ^~~~~~~
> x.c:10:84: note: aliased declaration here
>  (__optimize__ ("-fno-stack-protector"))) __typeof (__libc_memmove)
> *__libc_memmove_ifunc (void)
>                                                                      ^~
> ~~~~~~~~~~~~~~~~~~

Thanks.  I think the warning is working correctly, but I'm not
sure I completely understand the circuitous definitions or how
they are supposed to work.  They do appear to play tricks that
aren't type safe.

It looks to me like the file declares the __libc_memmove symbol
to have the same type as memmove.  It then defines the
__libc_memmove_ifunc function as an ifunc resolver for memmove
(i.e., a function that returns a pointer to memmove).  But it
also defines __libc_memmove as an alias for __libc_memmove_ifunc
and then memmove as an alias for the redefined __libc_memmove
with __libc_memmove_ifunc's type, and that's what GCC sees and
complains about.

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?

Martin