Replacing Ld with Gold - Any Experience

Replacing ld with gold - any experience?

At the moment it is compiling bigger projects on Ubuntu 10.04. Here you can install and integrate it easily with the binutils-gold package (if you remove that package, you get your old ld). Gcc will automatically use gold then.

Some experiences:

• gold doesn't search in /usr/local/lib
• gold doesn't assume libs like pthread or rt, had to add them by hand
• it is faster and needs less memory (the later is important on big C++ projects with a lot of boost etc.)

What does not work: It cannot compile kernel stuff and therefore no kernel modules. Ubuntu does this automatically via DKMS if it updates proprietary drivers like fglrx. This fails with ld-gold (you have to remove gold, restart DKMS, reinstall ld-gold.

Is the lld linker a drop-in replacement for ld and gold?

One of the LLD developers, Rui Ueyama, looks back at the progress LLD did in 2016, see http://lists.llvm.org/pipermail/llvm-dev/2016-December/107981.html.

• "Now I'm pretty sure that that [LLD] is going to be a serious (and better, in my opinion) alternative to the existing GNU linkers [..]."
• "LLD is now able to link most x86-64 userland programs."
• "The FreeBSD project and we are trying to make LLD the system default linker of the operating system, and except a few tricky programs such as the kernel or a bootloader, the linker works mostly fine." Already achieved!
• "LLD supports x86, x86-64, x32, AArch64, AMDGPU, ARM, PPC64 and MIPS32/64,
  though completeness varies."
• "[T]here are already a few systems that are using LLD as system
  linkers, such as CloudABI or Fuchsia. Chromium and Clang/LLVM itself has
  build options to use LLD to build them."

And, as a bonus:

• "LLD got faster [..] At the beginning of this year,
  LLD took about 16 seconds to produce a 1.5 GB clang (debug build)
  executable. Now, it takes about 14.5 seconds on single core and 8.5 seconds
  on 20 cores. ld.gold takes about 25 seconds and 20 seconds,
  respectively. [..] If you have a problem of too long link time, I'd recommend to try LLD."

Update spring 2017 According to one of the developers "LLD/ELF is now ready for production use at least for x86-64 (and probably for AArch64 and MIPS).", see http://lists.llvm.org/pipermail/llvm-dev/2017-March/111083.html
It also contains a brief description on how to make use of LLD.

How to link with the GNU gold linker instead of ld in Haskell

Link 3x faster with gold

Since GHC 7.8, you can tell GHC and cabal (at run time without having to recompile GHC) to link with GNU gold.

You need in your .cabal file:

library:
  ghc-options: -optl-fuse-ld=gold
  ld-options:  -fuse-ld=gold

executable myExecutable
  ghc-options: -optl-fuse-ld=gold
  ld-options:  -fuse-ld=gold

(Note you might want to pass these flags to stack/cabal/Setup.hs on the command line instead of hardcoding them in the .cabal file in order to not reduce the portability of the package.)

For me it's 3.5x faster, bringing down the total link time of a project from 150 seconds to 40 seconds.

---

Update: Link 10x faster with lld

See https://github.com/nh2/link-with-lld-example for a full example; key parts:

library
  ghc-options: "-pgmP clang" "-pgmc clang" "-pgma clang" "-pgml clang" "-optl-fuse-ld=lld"
  ld-options:  -fuse-ld=lld

executable myExecutable
  ghc-options: "-pgmP clang" "-pgmc clang" "-pgma clang" "-pgml clang"
  ld-options:  -fuse-ld=lld

Comparison of link time for the final executable link times my project:

ld   124 seconds
gold  36 seconds
lld   11 seconds

Is binary linked with gold linker running faster?

Naturally, different linkers will produce different results, just like different compilers do. The result mostly depends on the optimization options that are enabled (and available) on each linker. Here is one possible reason for the differences you see, but there can be numerous others:

-fipa-icf

Perform Identical Code Folding for functions and read-only variables. The optimization reduces code size and may disturb unwind
stacks by replacing a function by equivalent one with a different
name. The optimization works more effectively with link time
optimization enabled. Nevertheless the behavior is similar to Gold
Linker ICF optimization, GCC ICF works on different levels and thus
the optimizations are not same - there are equivalences that are found
only by GCC and equivalences found only by Gold.

from: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Last but not least: there are many environmental factors that can affect the runtime besides the actual binary content. E.g., cache thrashing can have a considerable effect on the execution time. Also, set of 10 executions is too small for statistical conclusions.

Gold linker ld.gold -plugin : unknown option

The problem is not that the -plugin option should be --plugin. ld.gold
accepts both options if it accepts either of them.

But it only accepts either of them if the build of binutils has been
configured with --enable-plugins. Documentation.

When you run ld.gold --help | grep "plugin" the output shows that --plugin is
a recognized option.

Therefore the problem appears to be this:-

/home/nschoe/workspace/webrtc/jingle/trunk/third_party/binutils/Linux_x64/Release/bin/ld.gold
has not been configured with --enable-plugins

When you run ld.gold --help | grep "plugin" you are executing the first ld.gold
that is found on your PATH. It is probably /usr/bin/ld.gold from your distro. You
can find out by running:

which ld.gold

Anyhow, it isn't
/home/nschoe/workspace/webrtc/jingle/trunk/third_party/binutils/Linux_x64/Release/bin/ld.gold
and it is an ld.gold that has been configured with --enable-plugins

If you cd into /home/nschoe/workspace/webrtc/jingle/trunk/third_party/binutils/Linux_x64/Release/bin/
and run:

 ./ld.gold -plugin

you will get:

./ld.gold: -plugin: unknown option

To fix the problem the ideal solution is to rebuild /home/nschoe/workspace/webrtc/jingle/trunk/third_party/binutils
as per that Documentation

If you cannot rebuild these third party binutils from source then it will
probably work if you just copy the system ld.gold detected by which over the one in the
third party binutils, or delete/rename the third party one and replace it with a symlink
to the system one. There is an outside chance that either of the these hacks
would cause you some obscure breakage.

---

Related Topics