llvm dev - Oct 2016 - LLD to be the default linker in Clang

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.

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

Once it becomes available, having it means you should really use it.

Looks like a no-brainer to me. Am I missing something?

cheers,
--renato

On Fri, Oct 28, 2016 at 9:17 AM, Renato Golin via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> 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.
There's also -fuse-ld
That's how I usually do it.
> 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.
>
> Since it's not available by default in most of them, its existence
> means intention.
>
> Once it becomes available, having it means you should really use it.
>
> Looks like a no-brainer to me. Am I missing something?
>
> cheers,
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

On 28 October 2016 at 17:41, Hans Wennborg <hans at chromium.org>
wrote:
> There's also -fuse-ld>
> That's how I usually do it.
Right, that gets rid of the override flag. Thanks! :)

But the arguments about the default and the cross-compilation error still stand.

cheers,
--renato

I did not realize LLD was already far enough along to use. I have a related
question: What about using LLD via library API?

I would love to link against LLD and call API functions instead of trying
to find the system linker and spawning a child process and having different
code for each system linker. If I could use LLD as a library that would be
one less moving part in my compiler, one less potential thing that could go
wrong for my users.



On Fri, Oct 28, 2016 at 12:17 PM, Renato Golin via llvm-dev <
llvm-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.
>
> Since it's not available by default in most of them, its existence
> means intention.
>
> Once it becomes available, having it means you should really use it.
>
> Looks like a no-brainer to me. Am I missing something?
>
> 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/3e8e5f37/attachment.html>

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>

Hello Renato,

Thanks very much for raising the topic. I've not got much to add to
what has already been said.

If I understand correctly there are two use cases that we would want
to consider separately:
- Using lld by default when clang is used on a platform such as linux
if it is installed.
- Using lld by default in build-bots and the llvm test-suite when it
is installed.

For the former, personally I think that clang should follow the
conventions of the platform wherever possible, i.e. on Linux ld is a
symlink to ld.XXX which may be ld.lld. I agree with Sean that some
documentation on how to set up and use lld would be very helpful and
would be a relatively cheap first step. Some status information about
how complete each target is would also be useful.

For the latter, I think it would at first be good to have a simple
option, or document options that would use lld. When all targets that
have an lld port can reliably run in the build and test environment we
can consider making it the default if it has been intentionally
installed. I don't have a strong opinion on how to set this up.

Peter


On 30 October 2016 at 01:43, Sean Silva <chisophugis at gmail.com>
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?)
> 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
>
>

On 30 October 2016 at 01:43, Sean Silva <chisophugis at gmail.com>
wrote:
> 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.
Hi Sean,

First of all, let me be clear: I'm not proposing we "flip the switch
globally" at all.

I'm well aware of the efforts in using LLD as the default linker, and
in no way I'm suggesting we "jump the gun" and derail their
efforts.

I was just adding another dimension, orthogonal to their efforts, in
hope more people would see the value of using LLD.

Richard's flag to switch behaviour between LLVM and System is a much
better proposal than mine, and achieves what I wanted to do in a much
nicer way.

The compiler-rt + libgcc_s vs. libunwind is a real problem that has no
nice solution today.

The bugs that we find in old linkers and can't fix because the
platform won't update or GNU won't re-relase is a real problem.

Each of those problems has a solution using compiler flags (the RT one
is not trivial), but all of them together do make Clang hard to use if
you want new functionality.

New uses building Clang/LLVM will *have* to rely on their system
libraries and tools, unless they use a myriad of magic flags, even
though they're building a linker, all necessary libraries, a debugger,
etc.

Making it the default is too big a hammer, but having one simple flag
(ex. --llvm-env or --llvm-tools + --llvm-libs) would make *all* those
problems go away.

On systems that really need to be self-consistent (I'm assuming
Windows), then this could be the default, and users would need to use
flags like --system-env, etc. instead.

cheers,
--renato

And there is https://reviews.llvm.org/D25263 which aims to add
CLANG_DEFAULT_LINKER just as there are CLANG_DEFAULT_CXX_STDLIB and
CLANG_DEFAULT_RTLIB to override the platform defaults ;-)
________________________________________
Von: cfe-dev <cfe-dev-bounces at lists.llvm.org> im Auftrag von Hans
Wennborg via cfe-dev <cfe-dev at lists.llvm.org>
Gesendet: Freitag, 28. Oktober 2016 18:41
An: Renato Golin
Cc: LLVM Dev; Peter Smith; Clang Dev; Adhemerval Zanella
Betreff: Re: [cfe-dev] LLD to be the default linker in Clang

On Fri, Oct 28, 2016 at 9:17 AM, Renato Golin via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> 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.
There's also -fuse-ld
That's how I usually do it.
> 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.
>
> Since it's not available by default in most of them, its existence
> means intention.
>
> Once it becomes available, having it means you should really use it.
>
> Looks like a no-brainer to me. Am I missing something?
>
> cheers,
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
cfe-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

On Fri, Oct 28, 2016 at 8:44 PM, Andrew Kelley via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I did not realize LLD was already far enough along to use. I have a related
> question: What about using LLD via library API?
>
> I would love to link against LLD and call API functions instead of trying
to
> find the system linker and spawning a child process and having different
> code for each system linker. If I could use LLD as a library that would be
> one less moving part in my compiler, one less potential thing that could go
> wrong for my users.
Ditto.

Tho you probably need to different code in order to find the system libraries.

Cheers, Jakob.

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