mold 0.9.4

mold is a new linker that is optimized for modern multi-core machines. mold is command-line compatible with the other major linkers, GNU ld, GNU gold and LLVM lld, yet it is several times faster than them. Its goal is to increase programmer productivity by speeding up program build time, especially for rapid edit-build-test-debug cycles.

Highlights of mold 0.9.4

• mold -run now intercepts invocations of ld, ld.lld and ld.gold wherever they are in the directory hierarchy. Previously, they were intercepted only if they were in /usr/bin. This change was made because it is not uncommon to install a compiler toolchain into a directory other than the system bin directory.
• AArch64 (Arm 64-bit) support has been significantly improved. mold can now link many real-world programs including itself for AArch64.
• Fix an issue that relocation addends were not handled correctly for i386.
• mold is now able to link LLVM compiler-rt's CRT files.
• Fix an issue that a dynamic relocation was created for a read-only section if the relocation refers an unresolved weak symbol.
• Undefined weak symbols are now always resolved to address 0 instead of being promoted to dynamic symbols.

mold 0.9.3

mold is a new linker that is optimized for modern multi-core machines. mold is command-line compatible with the other major linkers, GNU ld, GNU gold and LLVM lld, yet it is several times faster than them. Its goal is to increase programmer productivity by speeding up program build time, especially for rapid edit-build-test-debug cycles.

Highlights of mold 0.9.3

• The --sysroot option is improved so that it's behavior is compatible with GNU ld.
• Intel TBB concurrency library is now statically-linked to the mold executable.
• mold gained the initial AArch64 (ARM64) support. It is still in alpha and not usable for production though.
• mold can now be built with musl libc instead of with GNU libc.
• The VERSION linker script command is now supported.
• mold is now even faster for object files containing a lot of mergeable string contents. Clang-13 with debug info is an example of such input. mold used to take ~3.6 seconds to link it on a simulated 10-core machine. mold v0.9.3 can link it in ~2.3 seconds. That is ~35% speedup.
• Other various minor compatibility issues have been fixed.

mold 0.9.2

mold 0.9.2 is a maintenance release of the mold linker. It contains only bug fixe. There's no new feature since 0.9.1. Here is a list of notable changes:

• Some test scripts are fixed so that they pass on non-Ubuntu-20 systems
• The logic to find the location of mold-wrapper.so is generalized so that mold can be installed other than /usr/bin or /usr/local/bin
• R_386_TLS_IE relocation has been implemented to fix a compatibility issue with GCC
• Some assertion failures are fixed
• mold no longer replaces IFUNC with FUNC in a .dynsym
• Section header is now properly aligned in memory and on disk

mold 0.9.1

This is the same version as 0.9 except that the version number is bumped up to 0.9.1. In mold 0.9, mold --version printed out 0.1.1 instead of 0.9.

mold 0.9

mold is a new linker that is optimized for modern multi-core machines. mold is command-line compatible with the other major linkers, GNU ld, GNU gold and LLVM lld, yet it is several times faster than them. Its goal is to increase programmer productivity by speeding up program build time, especially for rapid edit-build-test-debug cycles. (Disclaimer: I'm the original creator of the current version of LLVM lld.)

Highlights of mold 0.9

In the mold 0.9 release cycle, we focused on improving compatibility with other linkers. To find out compatibility issues, we tried to build all Gentoo Linux packages in a Docker environment with mold being set to /usr/bin/ld (the default linker's path) and also run their unittests if available. Gentoo was an ideal distro to conduct this test because of its source-based package system. We then analyzed all build and test failures one by one and fixed almost all issues during this release cycle.

Quantitatively speaking, among 6769 Gentoo packages that we could built with GNU ld, mold succeeded to build 6746 packages. This is ~99.7% success rate. A small number of packages were unable to be built with mold or failed to complete their unittests for various reasons. You can see our analysis of the failures on this spreadsheet.

So, we believe that as long as you are building your user-land program on a relatively new Linux distro, chances are mold will "just work" for your program. We don't want to set a bar too high, but we believe that you probably wouldn't notice any difference except a short program link time. We bumped the mold's version from 0.1.1 to 0.9 to show that mold is getting ready for production.

If you experience any compatibility issue, please file a bug at https://github.com/rui314/mold/issues.

Changes in mold 0.9

• Following options have been added: --warn-unresolved-symbols --error-unresolved-symbols --relocatable -z muldefs -z nodump -z origin --unique``--unresolved-symbols -z text -z textoff z notext -z keep-text-section-prefix --allow-multiple-definition --compress-debug-info=zlib{,-gnu,-gabi,none} -R --retain-symbols-file --warp --image-base
• mold used to embed its command line arguments to .comment section for traceability. Even though it's useful for debugging, it causes some OCaml tests which compare linker's output files byte-by-byte to fail. To appease them, mold embeds command line arguments to .comment only when MOLD_DEBUG environment variable is set to a non-empty string.
• mold now writes relocation addends to sections even for RELA-type dynamic relocations. This is for bug-compatibility with Go. Go's linker wrongly assumes that addends are always written to sections, although the correct value are in fact in RELA-type relocation themselves.
• mold now handles common symbols as if they were undefined symbols until a symbol resolution phase is done. This change makes an observable difference if an object file contains a common symbol and an archive file contains a non-common definition of the symbol. Previously, mold didn't pull out an object file from an archive to resolve a common symbol. Since mold 0.9, it pulls out an object file in that case. This change was made to build programs compiled with GNU Fortran.
• mold now exports undefined weak symbol as an undefined weak dynamic symbol, so that the symbol gets another chance to be resolved at load-time.
• .gnu.warning.* sections are now not only ignored but also discarded.
• mold no longer put local symbols to the dynamic symbol table. This change reduces the size of the dynamic symbol table.
• mold used to handle .ctors and .dtors sections as a normal section. These sections contain pointers to functions that are executed on program start up and exit. Today, their roles are superseded by .init_array and .fini_array sections. mold 0.9 now supports a feature to translate .ctors and .dtors to .init_array and .fini_array at link-time.
• mold now skips a library found by -l option if it's not for the target architecture. For example, mold skips libraries for i386 when creating an x86-64 executable.
• mold now defines end, etext and edata symbols.
• The version string displayed for --version now contains not only GNU ld but also GNU gold. This change appease some configure scripts that expect GNU gold in the --version string. (I wrote an essay about this kind of issue a few years ago.)
• The help message displayed for --help now contains supported targets and supported emulations strings to appease some configure scripts.
• If -z keep-text-section-prefix is given, mold now keeps .text.hot, .text.unknown, .text.unlikely, .text.startup, and .text.exit sections as they are instead of merging them into .text section. This change should slightly improve code locality at runtime, as hot code and cold code are aggregated to different places.
• Other various compatibility issues were fixed.

Demonstration

Here is a side-by-side comparison of per-core CPU usage of lld (left) and mold (right). They are linking the same program, Chromium executable.

As you can see, mold uses all available cores throughout its run and finishes quickly. On the other hand, lld fails to use available cores most of the time and takes much longer to finish. This is the Amdahl's law in action — only a limited number of internal passes of lld are parallelized, while almost all internal passes of mold are parallelized. On this demo, the maximum parallelism is capped to 16 so that the bars fit in the screen.

mold 0.1.1

mold is a multi-threaded, high-performance linker that is developed as a drop-in replacement for GNU ld, GNU gold and LLVM lld. It is several times faster than these linkers and command-line compatible with them with a few exceptions. Note that even though mold can compiler large user-land programs, such as Chrome, Firefox or Rustc, it is still experimental. Do not use mold for production unless you know what you are doing.

To use mold, download source using git clone and follow the instructions on README.

Changes

• More command-line options were added for compatibility with GNU linkers
• A man page was added
• mold executable no longer has a dependency to shared object files in a build directory, which enables us to install mold under /usr/bin and clean a build directory
• A script to build a statically-linked mold executable in a Docker environment was added, so that it is easy to build mold on any machine as long as Docker works
• Git subrepositories are automatically checked out by make now
• Various bugs were fixed

mold 0.1

Although mold is still experimental, it can link many programs correctly, and its speed outperforms other linkers by a wide margin. I'm tagging version 0.1 to the repository, so that it is easy to create a binary package for Linux distributions. In the future, more structured release management is needed, but for now, I'm just tagging it as-is.