[llvm-dev] [cfe-dev] LLD to be the default linker in Clang

Sat Oct 29 17:43:31 PDT 2016

On Fri, Oct 28, 2016 at 9:17 AM, Renato Golin via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Folks,
>
> I'm creating a bootstrap buildbot on AArch64 with LLD and I just
> realised the "accepted" way to make clang call lld is to "symlink lld
> -> ld". I understand that's how every Linux system "chooses" the
> linker, but that makes deployment and validation quite cumbersome on
> GNU systems.
>
> I'd like to suggest a change in behaviour:
>
> // Some flag like --linker=<full path / bin on path>
> if (LinkerFlag) {
>   linker = Flag (linker);
>
> // triple != host
> } else if (CROSS_COMPILE) {
>   if (LLDSupports(triple))
>     linker = Find (LLD);
>   if (!linker)
>     linker = Find (triple-ld);
>   if (!linker)
>     ERROR; // *NOT* the system linker!
>
> // triple = host
> } else {
>   linker = Find (LLD);
>   if (!linker)
>     linker = Find (SYSLD); // OS-specific
>   if (!linker)
>     ERROR; // We tried!
> }
>
>
>   Rationale
>
> My reason is that, if you just build Clang, with or without LLD,
> everything works out of the box as you expect: Former uses LLD, latter
> uses the system's linker. If LLD is able to cross-compile to the
> target triple, and it's available, try that. Cross compilers should
> never use the system linker, as that's just silly.
>
> However, if you didn't build Clang or LLD and still want to force the
> linker (cross when clang gets it wrong, lld installed somewhere else,
> some non-sysroot alternative, ld when you have built lld), you'll need
> a flag. It doesn't really matter if GCC will ever use LLD, but it
> would be good to have Clang be able to specify which linker to use.
>
> We already have library flags, and we don't need an assembler flag, so
> the linker seems like the last option missing.
>
>
>   Use Case
>
> For example, it's perfectly reasonable to have GCC and Clang on the
> same system and to have LD and LLD installed / accessible. It's also
> perfectly reasonable to have GCC using LD and Clang using LLD on the
> same system. Today, that's not possible without changing the path for
> Clang and not GCC (cumbersome, to say the least).
>
> The environment above is *exactly* that of any buildbot trying to
> bootstrap Clang+LLD using GCC+LD. Iwant to have at least one for
> AArch64 and one for ARM, but it would be good to have the same thing
> for x86_64, too at the very least.
>
> I don't know much about FreeBSD, but they're moving LLD as the
> official linker in multiple platforms and they still have GCC/LD in
> ports. There will probably be corner cases...
>
>
>   Conclusion
>
> I think LLD is mature enough to be preferred over LD on the platforms
> it support, if available.
>

Has anyone done a Debian or Gentoo stress test? If that hasn't been done, I
expect there to be a long tail of bugs that it would be good to squash a
significant part of before risking exposing our users to them. Also, what
is the current status of FreeBSD Poudriere? (Ed, Davide?)
The magic of open source package systems means we can do a large amount of
the bug finding where we might otherwise rely on users; we should take
maximum advantage of that since it is not only easier than getting user bug
reports, but also helps avoid giving users a bad experience.

>
> Since it's not available by default in most of them, its existence
> means intention.
>

But what is their intention? To suddenly use LLD for all their builds that
use Clang? Maybe they have a particular project that happens to have an
annoyingly long final link, and they are only interested in using LLD for
just that project.

This same data point ("existence means intention") could be used to justify
that the user is already intending to use LLD, so they will just manually
add `-fuse-ld=lld` to their link command lines. The suggested change, when
viewed through the assumption that LLD's "existence means intention", is
really just meant to save the user from adding `-fuse-ld=lld` to their
LDFLAGS; and it does so in an arguably somewhat uncontrolled fashion (e.g.
installing an LLD package can cause Clang to change linker in the middle of
an already-running build; or in an already-generated Ninja build dir for a
CMake project). In the same vein as Richard's comment, we don't do that for
e.g. libc++.

Realistically, I think that the best course of action for getting more
people using LLD/ELF right now is:
1. make getting LLD as easy as possible (e.g. make sure it is available in
the main Linux package repos)
2. write a documentation page "how to try out LLD/ELF" that centralizes
various pieces of information, such as how to get LLD/ELF, the use of
-fuse-ld=lld, how to report bugs (e.g. explaining the use of --reproduce),
etc.

> Once it becomes available, having it means you should really use it.
>
> Looks like a no-brainer to me. Am I missing something?
>

We currently have both the FreeBSD and the PlayStation effort underway for
making LLD/ELF a default production system linker. IMO, we should wait for
at least one of those efforts to stabilize before contemplating "flipping
the switch" globally in the way you described. Also, ideally we'll be happy
with the results of some sort of Linux-specific testing such as building
Debian or Gentoo.

-- Sean Silva

>
> cheers,
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161029/bd2b6a2b/attachment.html>