Linkers are very much like hyperdrives. They're one of those ancient but ubiquitous technologies; no one knows how they work, but no one cares.
The basics of dynamic linking is actually pretty simple, but it's tricky to find reference materials outside of reading the source code itself. A modern, mature dynamic linker supports a lot of very interesting and very powerful features, from LD_PRELOAD to LD_AUDIT to `dlmopen` (linker namespaces.)
I wonder whether this new linker plans to support all of these advanced features.
I've spent some time with these features to accomplish tasks such as:
I think the LD_AUDIT approach taken by the latter project could also lead to re-implementing a dynamic linker in Python itself via the system's linker's auditing mechanism. This might be a very interesting educational exercise!
LD_PRELOAD and LD_AUDIT are the features of the dynamic linker or ld.so. The dynamic linker is a process to read an executable and DSOs in memory, fix up images in memory to make it really ready to be executed by a CPU. lld is a linker which creates executable or DSO files. That is different from the dynamic linker.
This may be a reference to a SciFi trope where a space faring society has use of hyperdrive technology that it bought/stole/inherited from an older civilization, but doesn't have any ability to create and/repair
" lld is not at feature parity with gold yet, so it is too early to make a conclusion, but we are working hard to maintain or improve lld’s speed while adding more features."
LLD does not yet support string section merging, which iant mentions is the slowest part of gold.
So wait, modifying gold to fix (or even remove) the slow string section merging wasn't a possibility? It sounds a lot less work than writing a completely new linker.
gold is GPL v3. Even if that route was less work, it wouldn't be compatible with the LLVM project's goal to produce a permissive-licensed suite of tools (UIUC, broadly similar to BSD).
This matters to important LLVM backers like Apple, who employ a lot of the core devs.
"LLVM project's goal to produce a permissive-licensed suite of tools"
This is really far down the goal list ;-)
"This matters to important LLVM backers like Apple, who employ a lot of the core devs."
As mentioned numerous times, the vast majority of core devs are non-Apple at this point.
More to the point here, the person who wrote the blog post, and is responsible for the vast majority of LLD as it exists today, ruiu, works at Google (happily, ELF is being pushed along by others as well)
I'm responsible for the entire C++ platform there, and I can happily state that i don't give a single whit about whether LLD is permissively licensed or not.
As I wrote in the blog post, we didn't take a closer look at the performance difference, and I know that "measure, don't guess" is maxim. But if I risk it, I believe there are some differences that could make a difference in performance as described in the following chapter. (This is for COFF but applicable to ELF.)
I'm guessing the speed difference comes from this linker using a different approach to symbol resolution which requires visiting files fewer times, but I'm not sure.
Probably because the GNU utils are written with support for each and every architecture and format in this world in mind.
lld however supports only x86_64, according to the blogpost. It's got to be fast if the cruft is cut.
What are the most dominant archs in actual usage today anyways? I'd guess x86(_64), armv6/v7/64, MIPS for cheap/crap routers and some SPARC... and ELF as the dominant binary format on *nix and PE/COFF on win32/64/arm.
While the gold linker is now part of the GNU binutils distribution, it's speed advantaged stem exactly from what you mentioned. The origin question is how lld can improve on that even further. Is there any document such as http://static.googleusercontent.com/media/research.google.co... for gold ?
"Unlike the GNU linker, gold doesn't use the BFD library to process object files. While this limits supported formats to ELF only, it's also claimed to result in a cleaner and faster implementation without an additional abstraction layer. Complete removal of BFD was cited as a reason to create a new linker from scratch rather than incrementally improve the GNU linker.[5]"
MIPS (Cavium and Broadcom) and PowerPC (Freescale QorIQ) are big players in the Networking market currently, but the next generation of processors from those companies mentioned above will be ARMv8
We're seeing a resurgence in multiple architectures as the world hurtles away from desktops.
While it's good to have GNU alternatives that do some things better, portability is more important than ever. This means we need to keep adding toolchains for new arches as they come up. For example, you missed Snapdragon and A4, which together are probably around a billion devices.
I don't want to detract from LLVM, but the community needs to keep the GNU one prospering if we want to avoid proprietary tool hell.
Aye, and the rest of the LLVM toolchain is supporting a huge number of architectures, some of which, like GPUs, that the GNU toolset doesn't support. Like any project, LLD is supporting the most popular architecture first, with roadmapped items for further architectures once that is finished. Keep in mind that binutils didn't support all the architectures it did with v1, it took porting work as well.
Furthermore, I'd disagree that the GNU binutils are the only toolset that are keeping us from proprietary hell. The LLVM development model, with fairly frequent releases and updates gives a huge push for toolchain users to contribute their patches. Sony, for example, had been grumpily looking at all the new features in LLVM being added as they were developing the toolchain for the PS4 because they couldn't add their contributions into the LLVM toolchain, and couldn't import the LLVM updates to avoid DNF syndrome.
I'd even go as far as to say that LLVM is our best hope of keeping the GNU project honest. A competing, Free, toolchain means that the GNU project cannot feign ignorance of the new features that llvm is bringing to the development table. The abilities that llvm offer are slowly trickling into gcc, even if certain parties are fearful of what effects those changes might bring. The right mix of cooperation and competition can and does bring wonderful things.
If any of the developers see this thread, does this new linker fix the issue of circular library dependencies requiring that a given library be specified multiple times? Also, can we get rid of the dependency on the order libraries are specified? IMO order of the libraries should not matter, just that they are all listed.
If you are talking about archive files (.a files), then the answer is yes. lld is not sensitive to the order of archive files in the command line. For any undefined symbol, if there exists a file that defined the symbol, the file gets linked no matter how files are ordered.
Congratulations to the contributors. A lot of this kind of work goes unnoticed by many. I personally appreciate the expertise and effort required to even be part of these achievements (though I share none of it myself). Based on the recent trend of posts on HN, I hope that others will see these efforts for what they are.
The basics of dynamic linking is actually pretty simple, but it's tricky to find reference materials outside of reading the source code itself. A modern, mature dynamic linker supports a lot of very interesting and very powerful features, from LD_PRELOAD to LD_AUDIT to `dlmopen` (linker namespaces.)
I wonder whether this new linker plans to support all of these advanced features.
I've spent some time with these features to accomplish tasks such as:
- embedding Python interpreters within themselves using `dlmopen` (linker namespaces): https://gist.github.com/dutc/cf808ec7d8e1c36e01cc https://gist.github.com/dutc/423d0d0ccba771cf910f https://gist.github.com/dutc/eba9b2f7980f400f6287 https://gist.github.com/dutc/2866d969d5e9209d501a
- writing LD_PRELOAD-like modules in Python: https://gist.github.com/dutc/6500c804b2f0141c9757
I think the LD_AUDIT approach taken by the latter project could also lead to re-implementing a dynamic linker in Python itself via the system's linker's auditing mechanism. This might be a very interesting educational exercise!