Re: [PATCH] Don't use IFUNC resolver for longjmp or system in libpthread (bug 21041)

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Aug 8, 2017 at 7:50 AM, Andreas Schwab <schwab@suse.de> wrote:
> Unlike the vfork forwarder and like the fork forwarder as in bug 19861,
> there won't be a problem when the compiler does not turn this into a tail
> call.
>
> Andreas.
>
>         * nptl/pt-longjmp.c (longjmp, siglongjmp): Don't use IFUNC resolver.
>         * nptl/pt-system.c (system): Likewise.


Missing BZ #.

Can you add a testcase from

https://sourceware.org/bugzilla/show_bug.cgi?id=21041


> diff --git a/nptl/pt-longjmp.c b/nptl/pt-longjmp.c
> index 2ef757e687..8f3c6b3a09 100644
> --- a/nptl/pt-longjmp.c
> +++ b/nptl/pt-longjmp.c
> @@ -25,21 +25,14 @@
>     symbol in libpthread, but the historical ABI requires it.  For static
>     linking, there is no need to provide anything here--the libc version
>     will be linked in.  For shared library ABI compatibility, there must be
> -   longjmp and siglongjmp symbols in libpthread.so; so we define them using
> -   IFUNC to redirect to the libc function.  */
> +   longjmp and siglongjmp symbols in libpthread.so.
>
> -#if SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_22)
> -
> -# if HAVE_IFUNC
> -
> -#  undef INIT_ARCH
> -#  define INIT_ARCH()
> -#  define DEFINE_LONGJMP(name) libc_ifunc (name, &__libc_longjmp)
> -
> -extern __typeof(longjmp) longjmp_ifunc;
> -extern __typeof(siglongjmp) siglongjmp_ifunc;
> +   With an IFUNC resolver, it would be possible to avoid the indirection,
> +   but the IFUNC resolver might run before the __libc_longjmp symbol has
> +   been relocated, in which case the IFUNC resolver would not be able to
> +   provide the correct address.  */
>
> -# else  /* !HAVE_IFUNC */
> +#if SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_22)
>
>  static void __attribute__ ((noreturn, used))
>  longjmp_compat (jmp_buf env, int val)
> @@ -47,14 +40,10 @@ longjmp_compat (jmp_buf env, int val)
>    __libc_longjmp (env, val);
>  }
>
> -# define DEFINE_LONGJMP(name) strong_alias (longjmp_compat, name)
> -
> -# endif  /* HAVE_IFUNC */
> -
> -DEFINE_LONGJMP (longjmp_ifunc)
> -compat_symbol (libpthread, longjmp_ifunc, longjmp, GLIBC_2_0);
> +strong_alias (longjmp_compat, longjmp_alias)
> +compat_symbol (libpthread, longjmp_alias, longjmp, GLIBC_2_0);
>
> -strong_alias (longjmp_ifunc, siglongjmp_ifunc)
> -compat_symbol (libpthread, siglongjmp_ifunc, siglongjmp, GLIBC_2_0);
> +strong_alias (longjmp_alias, siglongjmp_alias)
> +compat_symbol (libpthread, siglongjmp_alias, siglongjmp, GLIBC_2_0);
>
>  #endif
> diff --git a/nptl/pt-system.c b/nptl/pt-system.c
> index f8ca6ba0d9..b30ddf2b39 100644
> --- a/nptl/pt-system.c
> +++ b/nptl/pt-system.c
> @@ -25,29 +25,21 @@
>     libpthread, but the historical ABI requires it.  For static linking,
>     there is no need to provide anything here--the libc version will be
>     linked in.  For shared library ABI compatibility, there must be a
> -   'system' symbol in libpthread.so; so we define it using IFUNC to
> -   redirect to the libc function.  */
> +   'system' symbol in libpthread.so.
>
> -#if SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_22)
> -
> -# if HAVE_IFUNC
> -
> -extern __typeof(system) system_ifunc;
> -#  undef INIT_ARCH
> -#  define INIT_ARCH()
> -libc_ifunc (system_ifunc, &__libc_system)
> +   With an IFUNC resolver, it would be possible to avoid the indirection,
> +   but the IFUNC resolver might run before the __libc_system symbol has
> +   been relocated, in which case the IFUNC resolver would not be able to
> +   provide the correct address.  */
>
> -# else  /* !HAVE_IFUNC */
> +#if SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_22)
>
>  static int __attribute__ ((used))
>  system_compat (const char *line)
>  {
>    return __libc_system (line);
>  }
> -strong_alias (system_compat, system_ifunc)
> -
> -# endif  /* HAVE_IFUNC */
> -
> -compat_symbol (libpthread, system_ifunc, system, GLIBC_2_0);
> +strong_alias (system_compat, system_alias)
> +compat_symbol (libpthread, system_alias, system, GLIBC_2_0);
>
>  #endif
> --
> 2.14.0
>
>
> --
> Andreas Schwab, SUSE Labs, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."



-- 
H.J.