Re: [PATCHv2] Fix float128 IFUNC relocations on ppc64le [BZ #21707]

[Carlos O'Donell <carlos at redhat dot com>]

On 07/08/2017 02:31 PM, Tulio Magno Quites Machado Filho wrote:
> Changes since version 1:
> 
>  - Added a testcase.  This is now validating both statically and
>    dynamically linked executables.
>  - Fixed an issue in the $(foreach ..) in sysdeps/powerpc/powerpc64le/Makefile.
>  - Added a comment to csu/libc-start.c
>  - Added a comment to csu/libc-tls.c
My initial audit showed that no early loader usage of memcpy and memmove would
call IFUNC resolvers, and so this change was safe.

However, HJ is opposed to this change specifically for this reason because he
has optimizations to do what we said is not happening e.g. early IFUNC usage.

Therefore I see no way forward but to split the IFUNC initialization into two
pieces, something like:

setup_irel();

__libc_setup_tls ();

apply_irel();

Where ppc64le can do *everything* in setup_irel(); and nothing in apply_irel();
as a *temporary* bandaid for glibc 2.26.

In the future we need to discuss in more detail exactly what IFUNC's are allowed
and not allowed to do, and if we argue that they can use TLS then we will need
to adjust our infrastructure to setup TLS before the IFUNCs are used, and that
may mean doing a bootstrap/reapplication of IFUNC relocations along the same
vein as Florian was working on during the last release cycle.

We should all acknowledge the following:

* It is important that static and dynamic applications behaviour is as close to
  similar as possible. This reduces problems for developers.

* We should strive to reduce per-architecture IFUNC differences since this again
  is a complication for developers.

With these things in mind we know that making this fix for ppc64le is a temporary
solution that we need to backout once we have better IFUNC infrastructure.

-- 
Cheers,
Carlos.