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?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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?

Zachary Turner via cfe-dev
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? 

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Zachary Turner 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

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Zachary Turner via cfe-dev
In reply to this post by Zachary Turner via cfe-dev
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.

On Fri, Dec 14, 2018 at 9:22 AM Ben Grasset via cfe-dev <[hidden email]> 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? 
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev