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

[Martin Sebor]

On 09/20/2017 09:37 AM, Steve Ellcey wrote:
> On Tue, 2017-09-19 at 09:16 -0600, Martin Sebor wrote:
>> On 09/18/2017 03:44 PM, Joseph Myers wrote:
>>>
>>> On Mon, 18 Sep 2017, Martin Sebor wrote:
>>>
>>>>
>>>> It's meant as an escape hatch.  It allows declaring compatibility
>>>> symbols, for example by the libstdc++ _GLIBCXX_3_4_SYMVER macro
>>>> defined in libstdc++-v3/src/c++98/compatibility.cc.  The macro is
>>>> used to declare compatibility functions of all sorts of
>>>> incompatible
>>>> types.  The originally posted patch had libstdc++ disable the
>>>> warning
>>>> for the file with the symbols but Jonathan preferred this
>>>> solution.
>>>>
>>>> It could perhaps be tightened up to detect some of the cases on
>>>> your
>>>> list but I'm not sure it's worth the effort and added complexity.
>>>> Let me know if you feel differently (or have a different
>>>> suggestion),
>>>> otherwise I will go ahead and commit the patch as is.
>>> Please add a comment explaining this reasoning and commit the
>>> patch.
>> Done in r252976.
>>
>> Thanks
>> Martin
>
> This patch is causing my gcc/glibc ToT build to fail on aarch64.  I am
> not sure if everything should be working at this point or not or if
> there is more that needs to be done.  The problem is with the memcpy,
> memmove, etc. ifuncs on aarch64.

The GCC bits should be working correctly.  The Glibc patches were
checked some time ago so it should build as well, and does on x86_64
and I believe also powerpc64le.  I didn't test aarch64 or multiarch
builds but the error below indicates a type mismatch between the alias
and the target (one is a memcpy-like function and the other a function
that returns a pointer to a memcpy-like function).  That's correct for
ifunc where the resolver returns such a pointer but not for the alias
which is expected to have the same type.

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

>
> Steve Ellcey
> sellcey@cavium.com
>
>
> In file included from <command-line>:0:0:
> ../sysdeps/aarch64/multiarch/memmove.c:38:31: error: ‘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)}’ [-
> Werror=attributes]
>  strong_alias (__libc_memmove, memmove);
>                                ^~~~~~~
> ./../include/libc-symbols.h:135:26: note: in definition of macro
> ‘_strong_alias’
>    extern __typeof (name) aliasname __attribute__ ((alias (#name)));
>                           ^~~~~~~~~
> ../sysdeps/aarch64/multiarch/memmove.c:38:1: note: in expansion of
> macro ‘strong_alias’
>  strong_alias (__libc_memmove, memmove);
>  ^~~~~~~~~~~~
> In file included from <command-line>:0:0:
> ../sysdeps/aarch64/multiarch/memmove.c:34:13: note: aliased declaration
> here
>  libc_ifunc (__libc_memmove,
>              ^~~~~~~~~~~~~~
> ./../include/libc-symbols.h:800:25: note: in definition of macro
> ‘__ifunc_resolver’
>
>    __typeof (type_name) *name##_ifunc (arg)    \
>                          ^~~~
> ./../include/libc-symbols.h:916:32: note: in expansion of macro
> ‘__ifunc’
>  #define libc_ifunc(name, expr) __ifunc (name, name, expr, void,
> INIT_ARCH)
>                                 ^~~~~~~
> ../sysdeps/aarch64/multiarch/memmove.c:34:1: note: in expansion of
> macro ‘libc_ifunc’
>  libc_ifunc (__libc_memmove,
>  ^~~~~~~~~~
> cc1: all warnings being treated as errors
>