[Compiler-rt][test] Fix circular link dependency between builtins and libc

[quic-garvgupt]

On AArch64, long double is IEEE 754 binary128 (quad-precision). There is no hardware support for 128-bit FP, so every long double operation is lowered by the compiler into calls to software builtins (__multf3, __divtf3, __addtf3, __subtf3, etc.) provided by libclang_rt.builtins.a.

Currently, the link order is libclang_rt.builtins.a -lc -lm. Builtins are scanned first after which symbols like logbl/scalbnl/fmaxl/hypotl are unresolved references that are resovled through libc.a. However, resolving the references to these symbols further lead to undefined references to __multf3, __divtf3, __trunctfdf2 etc. that can only resolved through builtins. This circular dep is found in some compiler-rt tests such as compiler_rt_logbl_test,
compiler_rt_scalbnl_test, compiler_rt_fmaxl_test, divtc3_test.

Fix this by wrapping the archives in a linker group (--start-group/--end-group), which instructs the linker to rescan all archives in the group until no new symbols can be resolved.

This error is exposed when bfd like linkers are used.

[efriedma-quic]

Is this version what you meant to post? Code syntax seems broken.

What libc are you seeing this issue with?

[quic-garvgupt]

Is this version what you meant to post? Code syntax seems broken.

What libc are you seeing this issue with?

Thanks for pointing this out. I made an error while copying the changes from CPULLVM patch.

The issue is observed with picolibc but I presume the issue is libc agnostic. It's more that the issue is only exposed when bfd like linkers are used such as eld. I think until now, compiler-rt tests in LLVM are only linked with LLD mainly.

[github-actions]

✅ With the latest revision this PR passed the Python code formatter.

[efriedma-quic]

Adding --start-group looks like it's basically the same thing the clang driver does, so I guess that's fine.

[statham-arm]

The PR description doesn't seem to be describing a circular dependency, only the libraries being listed in the wrong order?

I certainly agree that libc and libm are likely to contain calls to compiler-rt builtins, and therefore builtins must be searched at least once after libc/libm have been processed.

But I'd expect the builtins library not to depend on libc/libm in turn. It's conceptually a lower-level thing. What goes wrong if you put %librt after libc and libm, instead of before? You've mentioned some libm → builtins dependencies, but you haven't mentioned any in the other direction which prevent you from just reordering the libraries.