[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
cfe-dev at lists.llvm.org
Fri Dec 14 11:10:42 PST 2018
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
More information about the cfe-dev