LLD is a linker developed by the LLVM project. It is a drop-in replacement for the system linker and aims to consume less resources than them.
LLD provides production-quality support for the following architectures:
- AArch64 and ARM
- LoongArch
- MIPS
- PowerPC and PowerPC64
- RISC-V
- x86-32 and x86-64
Despite this list, there is still one architecture supported by Fedora that was missing: s390x. This absence impacts how Fedora packages are built on s390x, either by prohibiting packages that require LLD or by requiring that the s390x package is linked with a different linker than other architectures. This difference is known to increase the maintenance burden because different linkers can behave differently.
The support for s390x was added to LLD 18.1. In this article, we explore the work involved in order to get the support for s390x upstream and all the tests that were implemented and executed.
The port
Porting LLD to s390x consists of implementing the open source ELF Application Binary Interface - s390x Supplement in LLD.
Adding support for a new architecture to LLD may benefit from previous work: LLVM already supported s390x and LLD already supported ELF files. That allows for the new s390x code in LLD to reuse both these implementations, reducing the development time.
The code implementing it has less than 700 lines. An important part of this code implements symbol relocation. More specifically, this code implements all the relocation types listed in section 2.4 of the ELF Application Binary Interface - s390x Supplement.
Functional testing
More than a half of the lines in the commit that adds support for s390x to LLD are related to the functional testing of the linker itself.
The 23 new tests evaluate if all the new implemented features are behaving as expected. They will help to identify regressions in new changes to LLD. For example, the test lld/test/ELF/systez-pie.s verifies if LLD can generate Position Independent Executables by parsing the ELF header, program headers, and the dynamic section looking for the expected values.
Sanity checking Fedora packages
After the implementation is complete, one question remains: is LLD ready to be used in order to link s390x software? The best way to answer this question is by linking software using LLD.
The Fedora community provides all the infrastructure needed to run this kind of test:
- copr provides the s390x servers that we can use to rebuild RPM packages and run their tests.
- mass-prebuild provides a way to create mass rebuilds in order to assess the stability of a given change.
First, we configured mass-prebuild in order to build LLD and set it as the default linker for our project in copr. We also listed more than 1,300 RPM packages. Mass-prebuild has a mechanism to identify packages with issues that should be ignored. By having a large number of packages, we are able to test a large group even if part of the packages are discarded.
After completing the mass rebuild, we investigated all the failures. Interestingly, this exposed issues in other projects that had never been built with a different linker on Linux on s390x. One example of these changes is a fix to Valgrind’s helgrind/tests/tc11_XCHG. LLD was able to detect and report a programming error that was generating a branch to an unexpected address.
Another source of valuable tests came from the ClangBuiltLinux project that build the Linux kernel using the tools from the LLVM project.
This work helped the Linux kernel community to identify and fix 5 issues upstream that blocked the usage of LLD when linking the Linux kernel for s390x:
- ld.lld: error: unknown argument ‘-fPIC’
- “writable SHF_MERGE section is not supported” lld error in s390 __bug_table sections
- ld.lld: error: relocation R_390_64 cannot be used against local symbol; recompile with -fPIC
- s390 “ld.lld: error: section … virtual address range overlaps with …”
- ld.lld: error: .btf.vmlinux.bin.o: unknown file type
Conclusions
The availability of LLD on all architectures supported by Fedora removes one of the barriers that caused Fedora to have fewer packages available on s390x. It helps to reduce the maintenance burden by allowing packages to use the same linker on all architectures.
It also helps to give a choice to s390x developers by providing and alternative linker that may reduce link time of large projects.
