Why isn't LD.LLD a drop-in replacement for GNU LD when built on Windows as part of a MinGW-W64 based LLVM/Clang toolchain?

Clang Frontend
1

As far as I can tell, it is literally the only tool in the entire LLVM/Clang ecosystem for which this is the case.

I.E. clang.exe works as a direct replacement for MinGW gcc.exe. clang++.exe works as a direct replacement for MinGW g++.exe. llvm-objcopy works as a direct replacement for MinGW objcopy.exe. llvm-objdump works as a direct replacement for MinGW objdump.exe. And so on.

Is it just one of those unfortunate worked-out-that-way-historically sort of things? Looking at the source repository it seems like there are a lot of things developed in the ELF folder that probably shouldn’t be ELF-specific, for example LinkerScript.cpp. To my mind linker script parsing has no reason to specifically by an “ELF” thing.

Are there any current plans to bridge this compatibility gap in the future?

2

Both yes and no, I guess.

As you've noticed, LLD consists of 3 (or 4) different separate linker implementations, for COFF, ELF, Wasm (and MachO). Each of them try to work as a drop-in replacement for the native linker on each platform.

In the COFF case, LLD, in the shape of lld-link, acts as a drop-in replacement for link.exe from MSVC. (Whether link.exe or ld.bfd is the true right linker to emulate as the native one can of course be discussed, but that decision is way before my time here.)

Since the 6.0 release, we've added another layer into the mix; if invoking ld.lld, which would normally be handled by the ELF linker, we check the -m parameter, and if it indicates that it should link for a COFF target (i386pe, i386pep, thumb2pe or arm64pe), it instead translates options from ld.lld style into lld-link style and invokes the COFF linker.

As the internal linker mechanisms within the COFF linker mimics link.exe and not ld.bfd, this emulation isn't perfect, but it does work in most cases now. This was first present in the 6.0 release, and since around September in the latest SVN trunk/upcoming 8.0 version, ld.lld should work in many cases as a replacement for ld.bfd.

It doesn't implement every single feature of ld.bfd, and it doesn't replicate ld.bfd's behaviour exactly (I just recently noticed one limitation, regarding linking crtend.o from libgcc, for i686 with dwarf exceptions), but for many cases it does work.

We haven't tried to implement every single option out there (not yet at least), but the most commonly used ones do work. (It's possible to compile all of VLC for Windows with it, which involves building over 100 various dependency libraries - although they are mostly built as static libraries so not all of them stress lld.)

Linker script isn't hooked up yet though. The only places I've ran into it being used for windows, is for passing lists of object files, which can be done just as well via response files. Therefore I've worked around that issue by adjusting build systems in a few places to use response files instead.

// Martin

3

Martin already replied, but I’ll add this history. Apologies for any inaccuracies.

Originally, there was a single LLD linker designed to handle all object file formats, ELF, COFF, MachO, and perhaps a new “LLVM native” format. The most active contributors at the time, Rui, Rafael, and maybe others I’m forgetting, found this very limiting, and it was very difficult to achieve their performance goals in that framework. So, a new COFF port was created, with the initial goal of being faster than and compatible with the MSVC linker. This effort was successful, so the same approach was applied to the ELF linker, but the codebases remained separate to prevent too many abstraction barriers from getting in the way of performance. I think there was also a desire to radically simplify the design and push any competing priorities, such as reusability as a library, out of scope.

Mingw support was added later as a secondary goal, and there is still a lot of tension between doing things the “gnu” way and doing things the Microsoft way. As a result, linker script support lives over in ELF land. I think retrofitting it into the COFF linker would be a major challenge. My understanding is that it was a large source of complexity for the ELF linker as well.