This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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/  The macro is
used to declare compatibility functions of all sorts of
types.  The originally posted patch had libstdc++ disable the
for the file with the symbols but Jonathan preferred this

It could perhaps be tightened up to detect some of the cases on
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
otherwise I will go ahead and commit the patch as is.
Please add a comment explaining this reasoning and commit the
Done in r252976.


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?


Steve Ellcey

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)}’ [-
 strong_alias (__libc_memmove, memmove);
./../include/libc-symbols.h:135:26: note: in definition of macro
   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
 libc_ifunc (__libc_memmove,
./../include/libc-symbols.h:800:25: note: in definition of macro

   __typeof (type_name) *name##_ifunc (arg)    \
./../include/libc-symbols.h:916:32: note: in expansion of macro
 #define libc_ifunc(name, expr) __ifunc (name, name, expr, void,
../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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]