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

  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?
>
> What is the preferred method for exposing ifunc'ed API?  I see both
> strong and weak aliases used in ppc multiarch code.  GCC claims only
> strong are supported, but both macros are used throughout ppc
> multiarch and seem to work.
This patch does not change if a symbol is weak or strong.
The current ifunc symbols reflect the behaviour of the common code.

>
> Likewise, many of the changes add an extra declaration for the
> ifunc'ed symbol.  Isn't this now handled by the __ifunc() macro?
> Can these redundant declarations be removed?
The extra declaration and the redirection is needed if you have an
internal __GI_* symbol which is directed to a dedicated fallback
variant instead of being the ifunc'ed symbol (see e.g. strncpy).

The libc_hidden_builtin_def(strncpy) creates the __GI_strncpy
symbol in sysdeps/powerpc/powerpc64/multiarch/strncpy-ppc64.c.
If gcc creates the ifunc symbol without the extra declaration and 
redirection and uses gcc-attribute-ifunc without 
libc_hidden_builtin_def(strncpy), then gcc produces an ifunced 
__GI_strncpy symbol but no strncpy symbol.
If you add the libc_hidden_builtin_def(strncpy), gcc produces
an ifunced strncpy symbol and an ifunced __GI_strncpy symbol.
In both cases you have two __GI_strncpy symbols and linking libc.so fails.

If the __GI_* symbol is ifunc'ed, too like stpcpy, you don't need the 
extra declaration and redirection.
Have a look at sysdeps/powerpc/powerpc64/multiarch/stpcpy.c.

But you are right, the extra declaration is not needed and if it is done
in the __ifunc() macro. See below.

>
> Simiarly, are all the macro redirections necessary? The redirects
> in s_finitef.c for double and long double seem unnecessary, and
> removing all them worked as expected.
Yes you are right. In s_finitef.c/s_isinff.c the redirects are not 
necessary. I can remove them.

>
> Maybe another macro like libc_ifunc_public would be useful to
> properly declare, and alias an indirect function?  That would
> simplify much ppc code.
The redirection in the header files can't be done within such a macro
because you have to do it before including the header file.
To make the declaration, the macro would need to get the redirected 
function name and the real function name. As it is only needed if 
redirection is needed, the macro name should reflect this and could be 
named libc_ifunc_redirected instead of libc_ifunc_public.
Then it could do something like that:
#define libc_ifunc_redirected (redirected_name, name, expr) \
extern typeof (redirected_name) __libc_##name __attribute__ (ifunc)\
static void *resolver(arg) {...}\
strong_alias (__libc_##name, name)

The usage in e.g. strnlen.c could be:
# define strnlen __redirect_strnlen
# define __strnlen __redirect___strnlen
# include <string.h>

extern __typeof (__strnlen) __strnlen_ppc attribute_hidden;
extern __typeof (__strnlen) __strnlen_power7 attribute_hidden;
# undef strnlen
# undef __strnlen

libc_ifunc_redirected (__redirect___strnlen, __strnlen,
             (hwcap & PPC_FEATURE_HAS_VSX)
             ? __strnlen_power7
             : __strnlen_ppc);
weak_alias (__strnlen, strnlen)

I've updated the patches with these changes.
Please have a further look.

Thanks
Stefan

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

Commit Message

Comments

Patch