[llvm-dev] Thoughts on the LLVM linker

Rui Ueyama via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 25 23:22:54 PST 2019

The reason why we have different command line interfaces for different
platforms is simply because they are actually different. It is not because
lld is Windows-centric (it's not.)

The native linkers for these major platforms (e.g. link.exe or /usr/bin/ld)
are quite different in terms of behavior. It's because native linkers have
evolved separately in their environment for dozens of years. Each linker
has evolved their own vocabulary (e.g. command line parameters) over the
course of their history, sometimes borrowing concepts and command line
flags from others, but they rarely made dead-copy features. Instead, they
adjusted concepts to fit to their platform. So even if two command line
options have the same or very similar names, they are not quite the same.
So, if you create a unified command line interface, you'd likely end up
with -unix-foo, -windows-foo, -mac-foo to support option -foo. You cannot
merge them to option -foo by ignoring subtle differences.

WebAssembly is quite new, but they are pretty different from other binary
formats because it is not a native binary format. For example, functions
don't have addresses in wasm because they live outside of the wasm
execution environment. As a result, even though wasm-ld borrows many
options from Unix, it naturally has many wasm-specific command line
options, and the options don't make sense for non-wasm targets.

The other problem of an imaginary unified driver is that it allows to use
impossible combinations of features. Most command line options make sense
for only one target, but if your linker accepts all options of all
platforms, you would have to define some reasonable behaviors for all
unprecedented combinations of features. That is actually a very difficult
problem to solve. (Of course you can solve the issue by disallowing all
combinations of command line flags of different targets, but that nullifies
the point of creating a unified driver.)

So, yeah, it may look a bit silly to have different command line interfaces
for all these targets, but I think it technically makes sense.

On Tue, Nov 26, 2019 at 2:49 PM Mikael Egevig via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
> I am using LLVM as the backend in a small hobby compiler project I'm
> working on.  I plan to support all platforms that LLVM supports (limited by
> my available hardware only).
> As far as I can tell, there are different linkers for the various host
> systems out there (the output of 'lld' if you invoke it on Arch Linux):
>     lld is a generic driver.
>     Invoke ld.lld (Unix), ld64.lld (macOS), lld-link (Windows), wasm-ld
> (WebAssembly) instead
> I am wondering if there are any plans to make a single, standard,
> cross-platform link tool so that people who are not locked into the
> Microsoft ecosystem (Visual Studio and command-line tools) can use the LLVM
> linker without having to maintain three driver interfaces.  If I am not
> mistaken, you today have to use three or four different interfaces,
> depending on the host platform, just to link a few files.
> The way I see it, a single LLVM-linker with the same options and syntax on
> all platforms would be highly beneficial to those who use LLVM as their
> backend through generating .ll files as input to the LLVM tool chain.
> P.S. I am aware that I can use Clang as a gigantic driver for the linking
> process, but I am trying to get rid of all Clang dependencies because it is
> not needed by my project in any way.
> Thank you,
> Mikael Egevig
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191126/34acc752/attachment.html>

More information about the llvm-dev mailing list