Published by rui314 over 3 years ago
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:
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 GCCIFUNC
with FUNC
in a .dynsymPublished by rui314 over 3 years ago
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.
Published by rui314 over 3 years ago
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.)
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.
--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
.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..gnu.warning.*
sections are now not only ignored but also discarded..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.-l
option if it's not for the target architecture. For example, mold skips libraries for i386 when creating an x86-64 executable.end
, etext
and edata
symbols.--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.)--help
now contains supported targets
and supported emulations
strings to appease some configure
scripts.-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.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.
Published by rui314 over 3 years ago
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.
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 directorymake
nowPublished by rui314 over 3 years ago
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.