Skip to content

mold 2.42.1

Latest
Latest

Choose a tag to compare

View all tags
@rui314 rui314 released this 11 Sep 12:51
v2.42.1
9b376bc

mold 2.42.1 is a new release of the high-speed linker. This release includes further performance improvements. Along with improvements made in recent releases, mold is as fast as or faster than other high-performance linkers, including LLVM lld and wild. We have also fixed several problems with LTO builds, debugging, and C++ exception handling in this release.

Plans for mold 3.0 and beyond

We would like to use this release note to share our plans for the future development of mold, as some of these plans involve major changes that are relevant to existing users.

Rewrite in Rust

We are rewriting mold from C++ to Rust, and 2.42.1 is likely to be the last C++ version of the linker unless we need to make another patch release. The Rust version of mold will be released as mold 3.0. A tool like mold needs to be developed with the expectation that it may remain in use for decades. Given that expected lifespan, mold is still relatively early in its life, and we believe that rewriting it in Rust at this point is the right decision.

When I started developing mold in 2020, Rust was still a relatively new language. By 2026, however, Rust has matured into a practical choice for systems software. Rust offers performance comparable to C++ while providing strong safety guarantees such as memory safety. If a C++ program can be rewritten in Rust without too much difficulty, rewriting it in Rust has become an increasingly attractive option.

Rewriting an established program like mold carries risks. Recent advances in AI-assisted coding have made large-scale rewrites considerably more practical, but they do not eliminate those risks, and we do not take them lightly. We understand that the stakes are high. People trust mold because it just works, and we cannot afford to lose that trust. Some users may understandably be concerned about this change, and we will keep that in mind throughout the rewrite. Our goal is that, from a user's perspective, mold 3.0 will continue to work just as before, with only the implementation under the hood having changed.

Make mold the default linker on Linux

Over the past 20 years, several fast linkers, including gold, lld, and mold, have been developed. Yet the system linker, /usr/bin/ld, on most Linux distributions is still GNU ld. As a result, link jobs that mold can finish in a few hundred milliseconds may still take several seconds, tens of seconds, or even minutes with the default linker. I think this is an unfortunate situation for the Linux community.

As the original author of both lld and mold, I think I bear some responsibility for this situation. I have spent a great deal of effort making linkers faster, but not enough effort on the compatibility work needed to make a fast linker suitable as a drop-in replacement for the system linker. With mold 3.0, we intend to change that. One of the main goals of the mold 3.x series is to make mold suitable for adoption as /usr/bin/ld by Linux distributions.

To achieve that, we first need to implement the missing linker script features so that mold can link not only user-space programs but also kernels and firmware. We will then conduct extensive compatibility testing and work closely with Linux distribution developers to make it practical for them to adopt mold as /usr/bin/ld. Making this happen is one of our highest priorities for mold 3.x.

Support incremental linking

I think the way I have talked about incremental linking in the past may have given a somewhat misleading impression. I am not against incremental linking. It was not originally a goal for mold because I believed we should first focus on making full links much faster. That has been my view since I started developing LLVM lld more than ten years ago.

Before lld, linking was much slower than it is today, but many developers somehow treated that slowness as a given. A common response was that, since linking was inherently slow, we should reduce the amount of linking work by implementing incremental linking. I thought that was too pessimistic and not the right way to approach the problem. Instead of working around slow full links, I wanted to attack the problem directly and make full links much faster, ideally approaching the speed of a simple file copy. My thinking was that, if full links were still not fast enough after that, we could then consider incremental linking.

Today, mold can link multi-gigabyte binaries in a second or two, and in many cases a full link is about as fast as simply copying a file of the same size. To put it plainly, we have largely solved the problem of slow linking that has frustrated developers for decades. That has made incremental linking much less urgent than it was when we started working on lld. The bottleneck in the edit-build-test cycle may now lie somewhere else in the toolchain. Improving compiler speed, for instance, may have a greater impact than making the linker even faster.

That said, if we can find a simple way to add incremental linking to mold, we would be happy to do so. It could still improve some workloads significantly. We are currently exploring designs that can provide those benefits while preserving mold's simplicity and reliability.

Bug Fixes and Compatibility Improvements in mold 2.42.1

  • Fixed unexpected aborts during C++ exception handling. An empty unwind record left by compiler optimizations could hide an existing exception handler from the unwinder, causing the program to abort even though the exception should have been caught. (5f71cbf)

  • Fixed spurious "duplicate symbol" errors when mixing LTO and non-LTO archives, and intermittent LLVM LTO failures involving undefined symbols such as __cxx_global_var_init.N. These errors could occur even when the input files contained all the necessary definitions. (8349c41, 92eb17a)

  • On Linux with memory overcommit disabled (vm.overcommit_memory=2), even a small link could fail with "fork: Cannot allocate memory". mold now commits memory as it needs it, allowing these builds to succeed without changing the system's memory policy. (d3cf4a2)

  • Fixed a spurious error about corrupted .sframe data when linking with glibc startup files on Ubuntu 25.10. The assembler can emit an empty section, which mold now accepts. (32626eb)

  • Fixed spurious relocation overflow errors in very large programs, including Godot sanitizer builds. We also fixed corrupted debug strings in huge builds that mix DWARF32 and DWARF64. (d00482d, 1f56c36)

  • Fixed two regressions introduced in 2.42.0 that affected tools reading mold's output. --emit-relocs could associate relocations with the wrong symbols, particularly on RISC-V and LoongArch. ABI checkers could also report spurious changes because symbols such as _DYNAMIC and _end had become global. (635956d, 450832d)

  • Builds that combine object files with -r before the final link no longer assign incorrect addresses to common variables. We also fixed a crash when -r processed CREL relocations in COMDAT groups. (64d7331, a718dbb)

  • Fixed version scripts silently exporting symbols they were meant to hide. local:*; now works without a space after the colon, and quoted names such as "operator delete[](void*)" are matched literally in version scripts and dynamic lists, as they are in GNU ld. (df35e2b, 28513b5)

  • The "refers to a discarded COMDAT section" error now names the object file containing the prevailing definition, making ODR violations easier to track down. mold also exits cleanly after reporting it. (e04dded, dd3cdb3)

  • --gdb-index, which helps GDB load large programs quickly, now works with DWARF 5 type units emitted by GCC with -gdwarf-5 and -fdebug-types-section. Previously, this combination could produce an unusable index. GDB versions that do not support the new index format fall back to reading the debug information directly. (0ddd5b0, 6b22256)

  • [AArch64] You can now use -z rewrite-endbr to reduce the attack surface of programs built with BTI. The compiler emits bti c landing pads for functions that may be called indirectly; mold can see which ones actually need them and replace the rest with NOPs. This does not affect paciasp landing pads used with -mbranch-protection=standard. (3d4dc72)

  • [ARM32] Fixed illegal instruction crashes in programs containing handwritten Thumb assembly. A branch to an ordinary label could be incorrectly changed into a branch that switches to ARM mode. (72a956d)

  • [RISC-V] Fixed cases where linker relaxation left functions incorrectly aligned or computed incorrect distances between labels. The alignment problem affected static glibc builds, including __sigsetjmp. (1e5d6ba, e2a28d6)

  • [PPC64V2] Fixed "undefined symbol" errors when building with GCC's -Os option. mold now supplies the helper routines GCC needs to save and restore floating point and vector registers. (32e7a1a)

  • [s390x] Fixed incorrect instruction encoding that could cause branches or memory accesses to use the wrong addresses. The bug affected several relocations with 12 bit displacements. (d55b408)

Acknowledgements

mold is an open source project, and we accept donations via GitHub Sponsors. We thank everyone who sponsors our project. In particular, we would like to acknowledge the following organizations and people who have sponsored $32/month or more during this release cycle:

Assets 10
Loading