This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/8] Use gcc attribute ifunc in libc_ifunc macro instead of inline assembly due to false debuginfo.
- From: Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Date: Tue, 2 Aug 2016 16:07:54 +0200
- Subject: Re: [PATCH 1/8] Use gcc attribute ifunc in libc_ifunc macro instead of inline assembly due to false debuginfo.
- Authentication-results: sourceware.org; auth=none
- References: <1466682952-6301-1-git-send-email-stli@linux.vnet.ibm.com> <23c1158b-a7b5-6da1-1ce4-90c6f0e9b733@linux.vnet.ibm.com> <579B6CD8.7030607@linux.vnet.ibm.com> <c70c9395-a6b8-b47d-6286-8e5540762f5e@linux.vnet.ibm.com>
On 08/01/2016 10:18 PM, Paul E. Murphy wrote:
On 07/29/2016 09:48 AM, Stefan Liebler wrote:
On 07/27/2016 07:28 PM, Paul E. Murphy wrote:
I'm suspecting this attribute is not always enabled on all toolchains.
Testing this out with the system toolchain on a ppc64le P8 Ubuntu 14.04 system,
I was greeted with:
../sysdeps/powerpc/powerpc64/fpu/multiarch/s_isinf.c:35:13: error: ifunc is not supported in this configuration
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
I've tested it on a ppc64 P7 RHEL 7 system with gcc 4.8.5 and there gcc/binutils have ifunc support. Why is ifunc not enabled in your gcc but binutils supports IFUNC? Is this related to ppc64le and/or Ubuntu 14.04 / 16.04?
Does someone know if gcc does not support ifunc on other architectures / distros?
I can't shine any light onto why, but it does demonstrate the need to
update the configury to check for this case, and handle it sensibly.
Currently it only checks whether binutils supports ifunc, and enables
multiarch in the absence of more specific options passed to configure.
Okay. Then I can add an extra configure check to test the gcc attribute
ifunc support. If there is no support, a fallback ifunc-macro which uses
the old behaviour could be used. Then it won't break the build but the
debuginfo is not correct, too. Perhaps this fallback can be removed in
future. Do you know if gcc in Ubuntu 16.04 has ifunc support for ppc64le?
Yes you are right. In s_finitef.c/s_isinff.c the redirects are not necessary. I can remove them.
I assume the same holds for the extra redirects in s_finite, s_isinf,
and s_isnan. Otherwise, the ppc specific changes are ok.
Compiling s_finite.c without redirecting __finitef fails due:
In file included from
../sysdeps/powerpc/powerpc64/fpu/multiarch/s_finite.c:22:0:
../include/math.h:15:18: error: ‘__finitef’ undeclared here (not in a
function)
hidden_proto (__finitef)
In include/math.h:
3: #include <math/math.h>
15: hidden_proto (__finitef)
In math/math.h:
76: #define __MATHDECL_1(type, function,suffix, args) \
extern type __MATH_PRECNAME(function,suffix) args __THROW
100: # define __MATH_PRECNAME(name,r) name##f##r
/* Include the file of declarations again, this time using `float'
instead of `double' and appending f to each function name. */
104: # include <bits/mathcalls.h>
In math/bits/mathcalls.h:
195: __MATHDECL_1 (int,__finite,, (_Mdouble_ __value)) __attribute__
((__const__));
Here is the declaration of "__finitef". Due to the redirection of
__finite to __redirect___finite we get the declaration of
__redirect___finitef instead of __finitef and thus __finitef is not
declared as recognized by gcc and we have to redirect
__finitef/__finitel, too.
The same applies to s_isnan.c and s_isinf.c.
Bye
Stefan