[PATCH 05/13] powerpc64le: link tests against ld.so

[Paul E Murphy]

On 3/6/20 6:31 PM, Joseph Myers wrote:
> On Fri, 6 Mar 2020, Paul E. Murphy wrote:
> 
>> In preparation for the transition of the format of long double - from
>> IBM Extended Precision to IEEE 754 128-bits floating-point - on
>> powerpc64le, this patch adds the linking of the loader to the tests for
>> long double, since after the switch they will also depend on
>> __parse_hwcap_and_convert_at_platform.
> 
> I'm afraid this patch looks unmaintainable.
> 
> It adds a duplicate list of libm tests, with no obvious logic for what
> goes in that list, to an architecture-specific Makefile.  That seems like
> a recipe for patches that add a libm test, changing only
> architecture-independent code, accidentally breaking the build for
> powerpc64le.
> 
> Things should be designed in such a way that normal
> architecture-independent changes, such as adding new libm tests, do not
> require any knowledge of the existence of such a powerpc64le-specific
> list.
> 
> As these are generally normal tests, not tests in tests-internal, I
> presume they do not in fact use any internal glibc interfaces and so would
> work fine when built with an installed compiler and glibc.  So I think you
> need to identify exactly what is different (to cause the problem this
> patch is addressing) between normal builds of user code with installed
> tools, and the build of tests as part of the glibc testsuite build, and
> fix that difference (globally, not limited to these particular tests or
> this particular architecture) in such a way that these tests just work
> without a duplicate architecture-specific list of tests being needed.
> 

I don't disagree.  I think this workaround can be unilaterally added to 
gnulib-tests on ppc64le [1].  Though, I suspect that this is not the 
most accurate solution.

Looking at the comments in Makerules:

# Compiler arguments to use to link a shared object with libc and
# ld.so.  This is intended to be as similar as possible to a default
# link with an installed libc.

and poking around with GCC, I admit I don't fully understand all the 
(seemingly) implicit behavior of the default linking command.  Does:

-Wl,--as-needed $(elf-objpfx)ld.so -Wl,--no-as-needed ... -lgcc_s ...

accurately match the behavior of the default link command on ppc64le?


[1] This change, and implied removal any f128-loader-link usage.

--- a/sysdeps/powerpc/powerpc64/le/Makefile
+++ b/sysdeps/powerpc/powerpc64/le/Makefile
@@ -5,7 +5,7 @@ type-float128-CFLAGS := -mfloat128
  # libgcc requires __tcb_parse_hwcap_and_convert_at_platform when built 
with
  # a binary128 type.  That symbol is provided by the loader on dynamically
  # linked executables, forcing to link the loader after libgcc link.
-f128-loader-link = -Wl,--as-needed $(elf-objpfx)ld.so -Wl,--no-as-needed
+gnulib-tests += -Wl,--as-needed $(elf-objpfx)ld.so -Wl,--no-as-needed

  # Bootstrapping code for enabling IEEE 128.  This can be removed and
  # any indirections simplified once IEEE 128 long double is enabled.