[cfe-dev] 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?

[Martin Storsjö via cfe-dev]

On Fri, 14 Dec 2018, Ben Grasset via cfe-dev wrote:

> 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? 

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