
New ELF Linker from the LLVM Project - Sindisil
http://blog.llvm.org/2015/11/new-elf-linker-from-llvm-project.html?m=1
======
jamesdutc
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:

\- embedding Python interpreters within themselves using `dlmopen` (linker
namespaces):
[https://gist.github.com/dutc/cf808ec7d8e1c36e01cc](https://gist.github.com/dutc/cf808ec7d8e1c36e01cc)
[https://gist.github.com/dutc/423d0d0ccba771cf910f](https://gist.github.com/dutc/423d0d0ccba771cf910f)
[https://gist.github.com/dutc/eba9b2f7980f400f6287](https://gist.github.com/dutc/eba9b2f7980f400f6287)
[https://gist.github.com/dutc/2866d969d5e9209d501a](https://gist.github.com/dutc/2866d969d5e9209d501a)

\- writing LD_PRELOAD-like modules in Python:
[https://gist.github.com/dutc/6500c804b2f0141c9757](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!

~~~
Aardwolf
Hyperdrives ancient technology? Are you from the future, or from the Star Wars
universe? :)

~~~
pacaro
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

------
evmar
It's curious that linking speed can be improved by so much when gold was
itself written for speed only 7 years ago. I wonder, what's the trick?

~~~
mschuster91
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.

~~~
chx
Are you sure MIPS is only used in crap routers? For example
[https://www.ubnt.com/edgemax/edgerouter-
lite/](https://www.ubnt.com/edgemax/edgerouter-lite/) this is MIPS as
documented for example
[https://wiki.gentoo.org/wiki/MIPS/ERLite-3](https://wiki.gentoo.org/wiki/MIPS/ERLite-3)
here. Also, one of the first 802.11ac Wave 2 routers from Xirrus, that's also
MIPS, isn't it? [http://www.wireless-mag.com/News/34108/xirrus-selects-
cavium...](http://www.wireless-mag.com/News/34108/xirrus-selects-cavium-
octeon-iii-processors-for-80211ac-wave-2-wi-fi-.aspx)

~~~
kenz0r
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

~~~
justincormack
Cavium is still producing MIPS64 as well as ARM64, although whether they will
continue to do so is unclear.

------
jbandela1
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.

~~~
rui314
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.

------
coderdude
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.

------
rando289
No mention of why this was rewritten, or any comparison to the existing
code...

