NetBSD Exploring LLVM's LLD Linker For Lower Memory Footprint

[phoronix]

Phoronix: 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...

http://www.phoronix.com/scan.php?page=news_item&px=NetBSD-LLD-Linker-Report

[cybertraveler]

This section of the blog post helped me to understand this issue more clearly:

The clang toolchain considers LLD an explicit part of this workflow, and — unlike GNU ld — ld.lld is not really suitable for using stand-alone. For example, it does not include any standard search paths for libraries, expecting the driver to provide them in form of appropriate -L options. This way, all the logic responsible for figuring out the operating system used (including possible cross-compilation scenarios) and using appropriate paths is located in one component.
However, Joerg Sonnenberger disagrees with this and believes LLD should contain all the defaults necessary for it to be used stand-alone on NetBSD. Effectively, we have two conflicting designs: one where all logic is in clang driver, and the other where some of the logic is moved into LLD. At this moment, LLD is following the former assumption, and clang driver for NetBSD — the latter. As a result, neither using LLD directly nor via clang works out of the box on NetBSD; to use either, the user would have to pass all appropriate -L and -z options explicitly.

Is it really a big problem if the "user" has to pass the appropriate -L and -z options to the LLD linker? Surely in 99% of cases, a higher level build script, "driver" or build tools are being used to call LLD indirectly anyway.

I understand why the clang guys might want to keep LLD super light and abstract rather than add lots of extra platform specific code to it. It keeps the tool smaller and simpler, thus easier to test, maintain and improve.

Good luck to the NetBSD guys though! I'm sure they'll figure something out.

[reavertm]

This section of the blog post helped me to understand this issue more clearly:



Is it really a big problem if the "user" has to pass the appropriate -L and -z options to the LLD linker? Surely in 99% of cases, a higher level build script, "driver" or build tools are being used to call LLD indirectly anyway.

I understand why the clang guys might want to keep LLD super light and abstract rather than add lots of extra platform specific code to it. It keeps the tool smaller and simpler, thus easier to test, maintain and improve.

Good luck to the NetBSD guys though! I'm sure they'll figure something out.

Deponds who is the "user" here. For building Netbsd packages, surely scripts, "eclasses", "bbclasses", "rpmbuild macros" will do the job for netbsd maintainers. But what if it's about ld provided for netbsd user. Requiring user to pass compiler internal/system library paths to buildsystem is not nice. None buildsystem known to me (for host arch use case, crosscompilation use cases are often more explicit wrt sysroot or sdk paths) expects that.