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
sell...@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
