libcxx: Fix libcxx test on aarch64 with libunwind

[zatrazz]

Summary

Some tests uses 'long double' to/from conversions and for some targets
they are provided by compiler runtime (either compiler-rt or libgcc).
However when building libcxx with linunwinder current test configuration
at target_info.py do not include the required libraries, as:

not llvm_unwinder:
  [-lgcc_s] [-lgcc] [...] [-lgcc_s] [-lgcc]

llvm_unwinder
  [-lunwind] [-ldl]

This causes some tests build issues with missing symbols on aarch64,
for instance, where 'long double' is a binary float with 128-bits with
mostly of internal operations being provided by software routines.

This patch changes how to define the default linker flags by:

not llvm_unwinder:
  [-lgcc_s] [-lgcc]

llvm_unwinder
  [-lunwind] [-ldl] [-lgcc_s] [-lgcc]

I checked and aarch64 and x86_64 with libcxx and libunwind (with and without
LIBCXXABI_USE_LLVM_UNWINDER).

[rmaprath]

I too noticed this very recently (on our non-bare-metal builds), and wondered why these dependencies are not included by default. Thanks for looking into it. I'll let someone familiar with the details approve.

[EricWF]

Urg... Not this again. This link order is important. I can't remember *why*, but libgcc has to appear both before and after pthread and libc IIRC. Either way the intention here is to mimic the output of Clangs driver. For example the order Clang generates on Linux is:

// clang++ -### -pthread -stdlib=libc++ -xc++ - < /dev/null
"-lc++" "-lm" "-lgcc_s" "-lgcc" "-lpthread" "-lc" "-lgcc_s" "-lgcc"

What link order does the compiler generate on your platform?

[zatrazz]

I tried to find why exactly libgcc has to appear before and after but I couldn't get any information from commit history. On my system (aarch64/linux) I am also getting "-lc++" "-lm" "-lgcc_s" "-lgcc" "-lpthread" "-lc" "-lgcc_s" "-lgcc".

I think we can got by the safe side and just add the final libgcc at the end for the soft-fp symbols.

[zatrazz]

What about this version? The only difference is for libunwind libgcc is still included.

[jroelofs]

Doesn't libgcc_s contain bits of gcc's unwinder?

[zatrazz]

Yes, but my understaning is the proposed link order will force libc++ to link against _Unwind* symbols from libunwind (this is what I am observing also).

[jroelofs]

This breaks the ODR... the behavior under those circumstances is undefined.

[zatrazz]

Yes, although in pratice for shared libraries this is not an issue (at least on Linux with current linker strategies). And I open for suggestion on how to proceed in this case since we have some other options:

1. Add the required soft-sp implementations when building for Linux (this might happen not only on aarch64, but any other ABI that defines long double using fallback soft-fp)
2. Remove the possible soft-fp usages on all the tests. However this will lead to possible remove *all* the FP cases if libcxx should be used in a pure soft-fp platform
3. Only allows the libcxx + linunwind to be built against compiler-rt

[jroelofs]

In D23420#513820, @zatrazz wrote:

Yes, although in pratice for shared libraries this is not an issue (at least on Linux with current linker strategies). And I open for suggestion on how to proceed in this case since we have some other options:

1. Add the required soft-sp implementations when building for Linux (this might happen not only on aarch64, but any other ABI that defines long double using fallback soft-fp)

Are the softfp symbols you need not contained in libgcc.a?

2. Remove the possible soft-fp usages on all the tests. However this will lead to possible remove *all* the FP cases if libcxx should be used in a pure soft-fp platform
3. Only allows the libcxx + linunwind to be built against compiler-rt

[zatrazz]

In D23420#513824, @jroelofs wrote:

In D23420#513820, @zatrazz wrote:

Yes, although in pratice for shared libraries this is not an issue (at least on Linux with current linker strategies). And I open for suggestion on how to proceed in this case since we have some other options:

1. Add the required soft-sp implementations when building for Linux (this might happen not only on aarch64, but any other ABI that defines long double using fallback soft-fp)

Are the softfp symbols you need not contained in libgcc.a?

Good call, I think just using 'lgcc' should be suffice. I will change the patch.

[zatrazz]

I think patch should be safe now.

[zatrazz]

Ping.

[zatrazz]

Ping (x2).

[jroelofs]

LGTM

test/libcxx/test/target_info.py

def add_cxx_link_flags(self, flags):
             flags += ['-lgcc_s', '-lgcc']
         if enable_threads:
             flags += ['-lpthread']
             if not shared_libcxx:
               flags += ['-lrt']
         flags += ['-lc']
         if llvm_unwinder:
             flags += ['-lunwind', '-ldl']
-        else:
-            flags += ['-lgcc_s', '-lgcc']
         use_libatomic = self.full_config.get_lit_bool('use_libatomic', False)
         if use_libatomic:
             flags += ['-latomic']
         san = self.full_config.get_lit_conf('use_sanitizer', '').strip()
         if san:
             # The libraries and their order are taken from the
             # linkSanitizerRuntimeDeps function in
             # clang/lib/Driver/Tools.cpp