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

On Sat, Oct 29, 2016 at 5:43 PM, Sean Silva via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
> 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?)
Last I tried to build all the FreeBSD package port collection (~25k
packages ranging from glib to gnome etc..) about 50% of them were
linked successfully, about 10% were failing and the rest were skipped
because dependent on something not linked correctly. This was at the
end of may, back then we didn't have linker scripts and version
scripts support, so, a bunch failures were due to missing features.
I think we're in good shape to try another run, I'll try to do it this
week (hopefully before the devsummit). Once we get results, that
should give us another view of the maturity of lld as a project.
Also, FWIW, Gentoo had a (successfully) completed project to build
using clang/llvm, and in my single interaction with the student he
said he tried lld but encountered some issues. I think it's worth a
shot.
Similarly, when I spoke with Saleem, he mentioned that something
similar can be done on Exherbo.
As a final note, something not very visible (for obvious reasons), we
link PS4 codebase(s) internally and we consider lld stable enough for
our purposes.

About the gcc patch to get -fuse-ld=lld to work I submitted , I think
that could be re-worked to make -fuse-ld a generic facility as it is
in llvm (i.e. you can pass an arbitrary absolute paths to
/my/shiny/linker), instead of hardcoding and matching on `=ld.bfd` and
`=ld.gold` as it's currently done. That should leave aside all the
non-technical concerns.

--
Davide

To add more reference points, we've been using LLD as a default linker on
Fuchsia from the beginning of the project. The only part of the system that
doesn't link with LLD at the moment is Magenta, our kernel, which relies
heavily on linker scripts and there are still several issues there. Once
those are ironed out, we would like to use LLD for everything.

We also use Clang as the host toolchain (because we default to C++14 for
all new code and we cannot guarantee that the host toolchain has C++14
support), including LLD as a linker to avoid having to ship ld.bfd or gold.
That's the reason I sent the https://reviews.llvm.org/D25263; I'd like
to
set the LLD as a default linker in our toolchain build even for the host to
avoid having to always pass -fuse-ld=lld when building host binaries.

On Mon, Oct 31, 2016 at 11:23 AM Davide Italiano via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Sat, Oct 29, 2016 at 5:43 PM, Sean Silva via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> >
> > 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?)
>
> Last I tried to build all the FreeBSD package port collection (~25k
> packages ranging from glib to gnome etc..) about 50% of them were
> linked successfully, about 10% were failing and the rest were skipped
> because dependent on something not linked correctly. This was at the
> end of may, back then we didn't have linker scripts and version
> scripts support, so, a bunch failures were due to missing features.
> I think we're in good shape to try another run, I'll try to do it
this
> week (hopefully before the devsummit). Once we get results, that
> should give us another view of the maturity of lld as a project.
> Also, FWIW, Gentoo had a (successfully) completed project to build
> using clang/llvm, and in my single interaction with the student he
> said he tried lld but encountered some issues. I think it's worth a
> shot.
> Similarly, when I spoke with Saleem, he mentioned that something
> similar can be done on Exherbo.
> As a final note, something not very visible (for obvious reasons), we
> link PS4 codebase(s) internally and we consider lld stable enough for
> our purposes.
>
> About the gcc patch to get -fuse-ld=lld to work I submitted , I think
> that could be re-worked to make -fuse-ld a generic facility as it is
> in llvm (i.e. you can pass an arbitrary absolute paths to
> /my/shiny/linker), instead of hardcoding and matching on `=ld.bfd` and
> `=ld.gold` as it's currently done. That should leave aside all the
> non-technical concerns.
>
> --
> Davide
> _______________________________________________
> 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/20161102/b25d7153/attachment.html>

I'm late to reply, but here's another data point which may or may not
have
been raised already:

In light of the whole mono-repo debate, assuming more people will have
a complete checkout of the project(s), it's the right thing to default
to preferring compiler-rt, libc++, libunwind, lld, over bintuils, libstdc++,
libgcc etc.

The major argument I can bring forward is that this will increase testing
and make the life of non-macOS environments aiming to make their base
env llvm-only a lot easier. This will surely make it easier for Linux distros
to default to the llvm toolchain, while keeping gcc/binutils in ports, so to
say, for the rare codebase that needs it (linux, glibc).

It may sound weird to use llvm instead of gcc as the base toolchain on Linux,
but there are linux distros which default to musl, and these are prime
candidates
to provide a llvm-default profile. Gentoo users can probably do this anyway,
but there's benefit to extending voidlinux's musl profile or alpine
linux's
only profile (musl) to use llvm. If anything, alpine being default for docker
images, it would increase real world testing even further.

In summary: yes, please.