NetBSD Exploring LLVM's LLD Linker For Lower Memory Footprint
The NetBSD project has been making good progress in utilizing the LLVM compiler stack not only for the Clang C/C++ compiler but also for the different sanitizers, the libc++ standard library for C++, and other improvements most of which are working their way into the upstream code-bases. One area of NetBSD's LLVM support being explored most recently is using the LLD linker.
NetBSD is exploring the use of the LLVM LLD linker over GNU's ld linker due to the lower memory footprint. LLD generally goes through far less RAM than the current GNU ld linker.
Thanks to work by Kamil Rytarowski and others, LLD could soon be linking NetBSD packages, but there is currently a technical disagreement over the Clang/LLD design. Kamil explained in a new blog post, "Fixing LLD to work with the current clang driver would require adding target awareness to LLD and changing a number of defaults for NetBSD based on the target used. However, LLD maintainer Rui Ueyama is opposed to introducing this extra logic specifically for NetBSD, and believes it should be added to the clang driver as for other platforms. On the other side, the NetBSD toolchain driver maintainer Joerg Sonnenberger blocks adding this to the driver. Therefore, we have reached a impasse that prevents LLD from working out of the box on NetBSD without local patches."
Once that disagreement is resolved though, the rest of the stars should align for LLD NetBSD linking. "At this point, it seems that using LLD for the majority of regular packages is a goal that can be achieved soon. The main blocker right now is the disagreement between developers on how to proceed. When we can resolve that and agree on a single way forward, most of the patches become trivial...Hopefully, we will able to finally find a way forward that does not involve keeping upstream clang driver for NetBSD incompatible with upstream LLD, and carrying a number of patches to LLD locally to make it work. The further goals include attempting to build the kernel and complete userland using LLD, as well as further verifying compatibility of executables produced with various combinations of linker options (e.g. static PIE executables)."
More details for those interested on the NetBSD blog.
NetBSD is exploring the use of the LLVM LLD linker over GNU's ld linker due to the lower memory footprint. LLD generally goes through far less RAM than the current GNU ld linker.
Thanks to work by Kamil Rytarowski and others, LLD could soon be linking NetBSD packages, but there is currently a technical disagreement over the Clang/LLD design. Kamil explained in a new blog post, "Fixing LLD to work with the current clang driver would require adding target awareness to LLD and changing a number of defaults for NetBSD based on the target used. However, LLD maintainer Rui Ueyama is opposed to introducing this extra logic specifically for NetBSD, and believes it should be added to the clang driver as for other platforms. On the other side, the NetBSD toolchain driver maintainer Joerg Sonnenberger blocks adding this to the driver. Therefore, we have reached a impasse that prevents LLD from working out of the box on NetBSD without local patches."
Once that disagreement is resolved though, the rest of the stars should align for LLD NetBSD linking. "At this point, it seems that using LLD for the majority of regular packages is a goal that can be achieved soon. The main blocker right now is the disagreement between developers on how to proceed. When we can resolve that and agree on a single way forward, most of the patches become trivial...Hopefully, we will able to finally find a way forward that does not involve keeping upstream clang driver for NetBSD incompatible with upstream LLD, and carrying a number of patches to LLD locally to make it work. The further goals include attempting to build the kernel and complete userland using LLD, as well as further verifying compatibility of executables produced with various combinations of linker options (e.g. static PIE executables)."
More details for those interested on the NetBSD blog.
2 Comments