[PATCH 1/8] Use gcc attribute ifunc in libc_ifunc macro instead of inline assembly due to false debuginfo.

[Stefan Liebler]

On 08/02/2016 04:07 PM, Stefan Liebler wrote:
> 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?
>
Hi,

this is an updated version of the patch.
It adds a configure check to test if gcc supports attribute ifunc 
feature as not all configurations have support.
As fallback the old behaviour is used for the libc_ifunc macros.

The libc_ifunc macro with the old behaviour fails if the ifunc'ed 
function has an internal symbol. gcc fails with:
error: ‘__EI___stpcpy’ aliased to undefined symbol ‘__GI___stpcpy’
    extern __typeof (name) __EI_##name \
                           ^
./../include/libc-symbols.h:412:29: note: in expansion of macro 
‘__hidden_ver1’
  #  define hidden_def(name)  __hidden_ver1(__GI_##name, name, name);
                              ^
./../include/libc-symbols.h:463:32: note: in expansion of macro ‘hidden_def’
  # define libc_hidden_def(name) hidden_def (name)
                                 ^
../sysdeps/powerpc/powerpc64/multiarch/stpcpy.c:37:1: note: in expansion 
of macro ‘libc_hidden_def’
  libc_hidden_def (__stpcpy)
  ^

Therefore there is now a new libc_ifunc_hidden macro which uses e.g.:
extern __typof(__stpcpy) __libc___stpcpy;
and generates an ifunc'ed __libc___stpcpy function.
Afterwards a strong alias is used to create the internal symbol (via 
libc_hidden_def) and the real one:
strong_alias (__libc___stpcpy, __stpcpy);

Gcc with attribute ifunc can handle this case without an extra __libc_* 
function.

I've updated the i386, x86 / ppc time, gettimeofday patch to reflect 
these changes, too.

Tested on 32/64bit intel, powerpc, s390.
Paul: Can you retest it on powerpc little endian?

Bye
Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-gcc-attribute-ifunc-in-libc_ifunc-macro-instead-.patch
Type: text/x-patch
Size: 62908 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160805/6aadb07f/attachment.bin>