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

[Richard Smith via llvm-dev]

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

> On 28 October 2016 at 18:12, Ed Maste <emaste at freebsd.org> wrote:
> > It should be possible to search the path for ld.lld first, then ld,
> > but to me it seems like it will just be more confusing.
>
> Hum, for me it would be less confusing. :)
>
> GCC uses bfd by default, LLVM uses LLD. If you want to change, use
> -fuse-ld.
>

I don't think that's a fair comparison. GCC uses the system linker by
default (whatever 'ld' happens to name). If ld is a symlink to lld, then
GCC uses lld by default.

That's actually part of a much larger pattern: Clang is currently set up to
act as a drop-in replacement for the system compiler. That means we use
libstdc++ (not libc++) by default on targets where it's the default C++
standard library, we use libgcc_s (not compiler-rt) by default on targets
where it's the default compiler runtime, and so on. That strategy has
worked well in getting us to where we are today.

But our needs today aren't the same as they were a few years ago; we don't
need to prove ourselves as much as we used to, and while we should keep
supporting the target defaults for the above components, perhaps it's time
that we start to prefer using LLVM components where available. At the very
least, I don't see a good reason why we would ever want to use libgcc_s in
a situation where compiler-rt (and libunwind) are available -- libgcc_s
does not contain some functions that LLVM implicitly adds calls to.

Perhaps we should have a flag to specify whether we prefer the canonical
tools and components for the target, or whether we prefer LLVM's versions
when available (falling back to the target components if not)?

What would be confusing in this scenario?
>
>
> > Clang's current approach (ld from $PATH by default, or ld.arg from
> > -fuse-ld=arg) suits us in FreeBSD. Today we have:
> >     /usr/bin/ld.bfd (GNU ld 2.17.50)
> >     /usr/bin/ld (ld.bfd symlink)
> >
> > We'll soon add
> >     /usr/bin/ld.lld
>
> This seems like a simple enough approach. I guess my problem is more
> about building toolchains than shipping them.
>
>
> > The only downside of -fuse-ld= that I'm aware of affects GCC only, not
> > Clang: GCC accepts only -fuse-ld=bfd and -fuse-ld=gold, and Davide's
> > patch to add -fuse-ld=lld was met with hostility. But that shouldn't
> > have any effect on Clang.
>
> Just had a look at the thread. Some silly comments were expected, but
> I think Davide has withdrawn his patch too early.
>
> AFAIK, there's absolutely nothing in the GCC license, moto and
> copyright statements that forbid the usage of a non-GNU linker, and
> the argument "lld has bugs" is pointless.
>
> I would try again.
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://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/20161028/f1d38a99/attachment.html>