Skip to content

Releases: rui314/mold

mold 3.0.0

Choose a tag to compare

@rui314 rui314 released this 05 Oct 10:23

mold 3.0.0 is a new major release of the high-speed linker. As we announced in the 2.42.1 release notes, we have rewritten mold from C++ to Rust, and this is the first release of the Rust version. 2.42.1 is the last release of the C++ version. The goal of mold 3.x is to close the remaining compatibility gaps with GNU ld, particularly in linker script support, and to pave the way for mold to be adopted as the default linker in Linux distributions.

mold 3.0 is meant to be a drop-in replacement for 2.42.1. It accepts the same command-line options, supports the same target architectures, and produces the same output except for the bug fixes listed below. Linking performance remains on par with 2.42.1. We verified compatibility by running the test suite on every supported target, comparing linker output across a broad range of real-world workloads and option combinations, and building all Gentoo packages. We found no regressions.

The move to Rust also makes mold safer with corrupted input files. The C++ version could read memory out of bounds on such input and crash with a segmentation fault. In mold 3.0, those reads are bounds-checked, so mold stops with a panic at the faulty access instead.

If you build mold yourself, note that the build system has changed. See "Build Changes" below.

Build Changes

  • mold is now built with Cargo instead of CMake. It requires Rust 1.95 or later and a C compiler. Run cargo build --release to build mold and ./install-mold.sh to install it; the install script accepts PREFIX and DESTDIR. The CMake options have been removed.

  • If you install mold's libraries into a directory other than $PREFIX/lib, such as /usr/lib64, set the MOLD_LIBDIR environment variable to that directory both when building and when installing mold, so that mold -run can find mold-wrapper.so.

  • mold no longer depends on oneTBB. It statically links mimalloc 3.5.3 as before; build with --features system-allocator to use the system's malloc instead. mold links the system's zlib if available and includes zstd and BLAKE3; set ZSTD_SYS_USE_PKG_CONFIG=1 to link the system's zstd. (56ee0f8)

  • The MOLD_TARGETS CMake variable has been replaced with Cargo features. As before, distributions should build mold for all targets.

  • The test suite now runs with cargo test instead of ctest. install-build-deps.sh has been replaced with install-test-deps.sh, which you need only to run the tests.

Bug Fixes and Compatibility Improvements

  • Fixed a crash when creating a statically-linked executable with a version script or --default-symver. (f10b0c4)

  • Fixed a crash or a corrupted output when the output file is also an input file, as in mold -r -o foo.o foo.o bar.o. (d2b88ab)

  • --gc-sections no longer removes the functions given by --init and --fini. (c9e4cc4)

  • Common symbols of the same name with different sizes now get the largest size and the strictest alignment, as in GNU ld and lld. (d5781d5)

  • --icf=safe no longer folds functions exported from a shared library, and --icf=all no longer crashes with --emit-relocs. (ceab12c, 3dcd1df)

  • A versioned reference such as foo@VER in a shared library no longer pulls in an archive member that defines an unversioned foo. (#1657) (44bfa2a)

  • Fixed several cases of nondeterministic output, in --dependency-file, --repro, -r with many COMDAT groups of the same name, and some dynamic relocations. (5164561, 6d33903, 51e23d4, 696ed71)

  • Fixed several -r bugs: C++ exceptions broke in code from the second and later input files; -x, -X and -s removed symbols that relocations referred to; --gc-sections dropped data that relocations referred to; sh_link of SHF_LINK_ORDER sections such as .ARM.exidx was not set; and mold crashed with --strip-debug and DWARF type units. (0e41bb9, 3717460, b2c3d1d, 9aacb62, a247ca2, e41ed90)

  • GOT-relative relocations such as R_X86_64_GOTOFF64, and R_ARM_REL32, against symbols defined in shared libraries silently got wrong addresses. They are now handled correctly or reported as errors. (#1668) (659780e, 7fe68bf)

  • Errors for PC-relative relocations that can't be used in position-independent output now explain the cause and how to fix it. (39e6a01, 17b7b85)

  • The following now cause errors instead of a broken output or a crash: --defsym aliasing a symbol defined in a shared library, an undefined non-weak hidden symbol in a shared library or with --unresolved-symbols=ignore-all, a --defsym value that doesn't fit in 64 bits, an allocated section that is also compressed, and --strip-all with --emit-relocs. (56b862b, b3566fa, e3a89f2, a980054, 8233a75)

  • --noinhibit-exec no longer crashes on references to symbols in discarded COMDAT groups. (8f17166, 80baa5d)

  • Options starting with a single dash are now read as GNU ld reads them. For example, -entry=main was read as -e ntry=main. (#1671, #1670) (830a860)

  • --dynamic-list-data, --lto-pseudo-probe-for-profiling and --thinlto-index-only no longer consume the next argument, and --no-color-diagnostics is now accepted. (2ca893e, 04b493e)

  • If a version script lists a symbol in more than one version node, the first one now takes precedence, as in GNU ld and lld. (b7048f5)

  • Fixed relative paths with -C, --chroot and --repro. (e3bc349, 04e7dd8, a368d22)

  • mold no longer reserves 8 GiB of virtual address space at startup, so it works under ulimit -v. (cc69390, b18be91)

  • MOLD_JOBS now works if XDG_RUNTIME_DIR is an empty string. (8a360ff)

  • Files created by --separate-debug-file no longer contain a .gnu_debuglink section. (#1656) (b56649e)

  • mold no longer creates the meaningless __start_EHDR, __stop_EHDR, __start_PHDR and __stop_PHDR symbols. (0ee71d3)

  • [AArch64][PPC32][ARM32] Fixed calls to static functions in other sections through range extension thunks, which jumped to wrong addresses in large programs such as the ARM64 debug build of Chromium. (4165d0e, 9b91621)

  • [AArch64] Added support for more relocation types, such as R_AARCH64_TSTBR14 and R_AARCH64_GOT_LD_PREL19. (96d0282, a4b64d8)

  • [ARM32] Added support for more relocation types, such as R_ARM_ALU_PC_G0 and R_ARM_THM_PC12, and fixed -r output for big-endian ARM. (c0f9cd6, 4c9aad3, 4c26f16)

  • [ARM32][i386] -r no longer corrupts instructions referred to by some branch and TLS relocations. (1b17bdf)

  • [RISC-V][LoongArch] Fixed calls to functions folded by --icf=all when relaxation shrinks them, and R_RISCV_64 and R_LARCH_64 relocations in 32-bit objects. (52febe9, 5b22233)

  • [RISC-V] Fixed TLSDESC with object files created by Clang 18, --emit-relocs with TLSDESC relaxation, the EF_RISCV_TSO flag, R_RISCV_ALIGN in -r output, and overflow checks for 32-bit PC-relative relocations. (fdf8422, 7c8b805, 6b60f75, 4ba7792, 85d55f3)

  • [LoongArch] Added support for TLSDESC in the extreme code model, and fixed wrong values of *64_PC_HI12 relocations and spurious overflow errors for TLS relocations. (a36a161, 8133938, 13e6cc0)

  • [PPC32][m68k] A GOT too large for the 16-bit offsets that -fpic code uses is now reported as an error instead of being silently truncated. (acc8854, 614e2a0)

  • [PPC64] Fixed IFUNC calls in statically-linked executables and @got references in hand-written assembly, and mold now synthesizes the _savegpr0_* family of functions for PPC64V1 as well. (d3b2a74, b34a308, efda2fc)

  • [SH4] Fixed a crash when calling a function that returns a ...

Read more

mold 2.42.1

Choose a tag to compare

@rui314 rui314 released this 11 Sep 12:51

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)

Acknowle...

Read more

mold 2.42.0

Choose a tag to compare

@rui314 rui314 released this 12 Aug 01:27

mold 2.42.0 is a new release of the high-speed linker. It includes the following new features and bug fixes.

New Features

  • We have made numerous optimizations throughout the linker during this release cycle. mold 2.42.0 should be noticeably faster than previous versions, especially when linking large programs on machines with many cores.

  • --pack-dyn-relocs=android and --pack-dyn-relocs=android+relr are now supported. These options encode dynamic relocations in the Android packed relocation format (APS2), which significantly reduces the size of the dynamic relocation table of Android binaries. (59957fc, 7a66f71, 400dfad)

  • --compress-debug-sections now accepts a compression level, such as zstd:9 or zlib:6. Plain zstd and zlib remain equivalent to zstd:3 and zlib:1, respectively, which were the previous hardcoded defaults. (56fc571, 0420959, 6695f13)

  • The -w and --no-warnings options are now supported. They suppress warnings and cancel --fatal-warnings, while real errors are still reported. This matches the behavior of lld. (51b9683)

  • The -Ttext-segment option, which sets the address of the first byte of the text segment, is now supported for compatibility with GNU ld. (ac73431)

  • mold now supports the SFrame version 3 stack unwinding format. SFrame is a compact alternative to .eh_frame used for asynchronous stack unwinding by profilers and debuggers. As of binutils 2.46, the GNU assembler emits SFrame version 3 when the --gsframe flag is given, so object files containing .sframe sections are becoming common. .sframe sections cannot be treated as opaque bytes; mold parses input .sframe sections, discards entries for functions removed by --gc-sections or --icf, and rebuilds a single merged section sorted by function address, along with a PT_GNU_SFRAME segment so that the runtime can locate it. Relocatable output (-r) is supported as well. (d0aa95a)

  • mold now discards temporary local symbols such as .L.str.42 by default, as lld does. Compilers emit a large number of such symbols for unnamed program elements, but they are compiler-internal; nothing references them through the symbol table, and debug info refers to their data by section offset. Discarding them makes large debug builds a few percent smaller and keeps compiler-internal labels out of symbolized addresses. The new --discard-none option restores the previous behavior. -r and --emit-relocs continue to keep all local symbols. (45dea59)

Bug Fixes and Compatibility Improvements

  • Fixed a longstanding ICF bug in which two functions with identical machine code but different exception tables or personality routines could be folded into one, changing which exceptions the surviving function could catch. (a06b623, 923df2f)

  • ICF no longer considers a relocation against a preemptible symbol equivalent to a relocation against another symbol whose body happens to be identical, since preemptible symbols can be interposed at runtime. (17e705e)

  • When ICF folds sections with different alignment requirements, the surviving section now gets the strictest alignment of the group. Previously, a function requiring 4-byte alignment could be folded into a less-aligned copy and placed at an odd address, which broke member function pointers on x86, as they use the least significant bit of the address to distinguish virtual functions from non-virtual ones. (899655b)

  • Fixed a spurious "refers to a discarded COMDAT section" error when linking a mix of LTO and non-LTO archive files. COMDAT group selection is now redone from a clean slate after LTO so that groups are chosen among the files that actually remain in the link. A race condition in COMDAT owner selection during LTO has also been fixed. (920a516, 2708ba6)

  • Fixed symbol resolution against shared libraries that contain legacy compatibility aliases created with .symver foo, foo@VER (defined dynamic symbols with the hidden-version bit set). mold mistakenly let such an alias satisfy unversioned references to foo, silently binding callers to the legacy implementation at runtime instead of the default version foo@@VER. (5898fbc)

  • mold now reads version information for undefined symbols in shared libraries. Previously, a versioned undefined reference such as foo@VER_1.0 in a shared library was looked up by its bare name, so a non-default versioned definition in another shared library did not satisfy it, and --no-allow-shlib-undefined could report a spurious "undefined symbol" error. In addition, undefined references whose version index is 0, which some old versions of GNU ld emit, are no longer silently ignored. (6b8293b, 6b0ecea)

  • A symbol exported with an empty default version (foo@@) is no longer hidden by a version script's local: *; wildcard, matching GNU ld. (71cbd79)

  • mold now reports an error if both foo@@VER and foo@VER are defined and exported, since they are duplicate definitions of the same versioned name. Previously, we silently emitted a dynamic symbol table containing two definitions of foo@VER, leaving it up to the dynamic loader which one a versioned reference binds to. GNU ld and lld reject this too. (fba0a21)

  • mold now reports an error for a shared library that contains a defined dynamic symbol whose version index is 0 (VER_NDX_LOCAL). Such a file is ill-formed; a certain version of GNU ld produced one, and mold previously ignored the symbol and reported a confusing "undefined symbol" error for a symbol that plainly exists in the library. (1fb2901)

  • mold now reports an error if a shared library is given as an input file in a static link. Previously, the file was silently ignored, producing an executable that crashes at runtime. GNU ld and lld reject this at link time, and so do we now. (2b60527)

  • Global symbols that are not exported to the dynamic symbol table are no longer demoted to local symbols in .symtab. Previously, in an ordinary executable, nm printed t main instead of T main, which misled tools that depend on symbol bindings. Only symbols hidden by visibility or localized by a version script are now emitted as local, following lld. (35f4a33)

  • With --gc-sections, sections whose names are valid C identifiers are no longer unconditionally treated as roots. They are now kept alive only if their __start_/__stop_ marker symbols are actually referenced. The old behavior could pull in unrelated code and cause spurious "undefined symbol" errors that GNU ld and lld do not produce. (384527f)

  • If all sections that referenced a shared library are removed by --gc-sections, the library's DT_NEEDED entry is now omitted, matching lld's behavior. (3d546cd)

  • --emit-relocs now rewrites relocations for instructions that the linker has relaxed, so that the emitted relocations match the output code. Previously, input relocations were copied verbatim, and the stale relocation types and offsets confused post-link tools such as BOLT. This applies to x86-64, i386, ARM64, s390x, RISC-V and LoongArch. (f147d78, ad4c489)

  • --gdb-index now produces bit-identical output regardless of the number of threads. (6f8d62e)

  • Fixed --gdb-index handling of DW_FORM_rnglistx range lists, which Clang emits. The generated address table could contain overlapping ranges, which GDB 17 detects, causing it to print a warning and ignore the index entirely. (70ca8ff)

  • mold no longer emits PT_INTERP when creating a shared library even if --dynamic-linker is given, matching GNU ld and lld. Shared libraries are loaded by the dynamic linker itself, so PT_INTERP serves no purpose in them. (10b37a8)

  • Fixed a PT_LOAD alignment issue for sections whose alignment is larger than the page size. The file offset is now adjusted so that p_offset and p_vaddr remain congruent modulo the alignment. (ad4a683)

  • Fixed a regression introduced in 2.41.0 in which a response file (@file) with a relative path could not be opened when the -C option was also given. (61933bf)

  • Glob patterns now accept ! as a negation marker in bracket expressions (e.g. [!abc]) in addition to ^, following the POSIX shell convention. Version scripts generated for lld use this form. (e2d0c1a)

  • DTPREL relocations in non-allocatable sections, which compilers emit for thread-local variables in debug info, are now supported on AArch64, m68k, RISC-V and SH4. (4b00446)

  • [i386] In-place relocation addends are now sign-extended when read. (85c115e)

  • [AArch64] Added support for the R_AARCH64_MOVW_PREL_G* relocations. (a0c46e9)

  • [SH4] Fixed dynamic relocations losing their addends. mold emitted symbolic dynamic relocations with the addend stored in the relocated p...

Read more

mold 2.41.0

Choose a tag to compare

@rui314 rui314 released this 13 Apr 12:45

mold 2.41.0 is a new release of the high-speed linker. It includes the following new features and bug fixes.

New Features

  • A new --zero-to-bss option has been added. When given, mold scans input data sections and converts all-zero sections into BSS (SHT_NOBITS), reducing output file size. This is especially useful for user-defined sections created with __attribute__((section(...))) containing uninitialized global variables, which GCC and Clang emit as regular data sections even when their contents are entirely zero. (847341d)

  • --print-gc-sections and --print-icf-sections can now take =FILE to save their output to a file (e.g., --print-gc-sections=output.txt). (7dd7db0)

  • A new MOLD_TARGETS CMake variable has been added that allows building mold with a limited set of supported targets to reduce build time. The use of this variable is discouraged unless you build mold frequently for personal use; distributions should not use it. (dce9ac1)

  • --gdb-index performance has been improved by eliminating unnecessary zero-initializations and parallelizing more of the index generation. (a4db238)

Bug Fixes and Compatibility Improvements

  • Fixed spurious "duplicate symbol" errors when linking with LTO. Archive members extracted pre-LTO could conflict with LTO output, causing false positives. (632a0ee)

  • Fixed --omagic to pack all sections into a single PT_LOAD segment, matching GNU ld behavior. Previously, it only flipped permissions to RWX but still emitted separate page-aligned segments. --omagic now also implies --Bstatic and disables RELRO. (a1ae8da)

  • Fixed corruption of the string table in separate debug files generated by --separate-debug-file, which caused GDB to refuse to load them or display corrupt symbol entries. (4cd4d56)

  • Fixed --separate-debug-file emitting a bogus "PHDR" section in the debug file. (4798f43)

  • Fixed --no-allow-shlib-undefined to correctly reject symbols provided by static objects with hidden visibility, and to avoid false positives when LTO optimizes away symbols that are still available from loaded shared libraries. (f6bb117)

  • Fixed --push-state/--pop-state not correctly tracking the --static flag. (001f718)

  • Fixed linker script processing to support AS_NEEDED inside INPUT or GROUP commands, which is used by GCC 16's libatomic linker script. (e0a6f8e)

  • Fixed a performance issue where fallocate on tmpfs was unexpectedly slow (nearly a second for a ~5 GiB file). mold now avoids calling fallocate on tmpfs. (fc96c1b)

  • Fixed RELRO segment alignment when -z separate-loadable-segment is given. The end of the RELRO segment is now properly page-aligned so the runtime can protect it. (9f463a6)

  • Fixed an issue where an IFUNC PLT entry was unnecessarily created in position-dependent executables when the ifunc was not referenced within the executable. (3ad34d4)

  • Improved LTO compatibility: mold now falls back to native code for GCC fat LTO objects when using the LLVM LTO plugin, and correctly preserves non-LTO comdat members in mixed LTO/non-LTO builds. (2a1e5c6, a660037, d4d5eae)

  • --no-threads is now respected with --compress-debug-sections. (fce89c2)

  • --section-order now reports an error if the specified order would cause section addresses to go backward. (91439be)

  • ICF now considers .gcc_except_table sections, improving deduplication accuracy for functions with exception handling. (fd86590)

  • Replaced an uninformative abort() with a descriptive error message when mold auto-detects an unsupported target. (93e1aea)

  • [AArch64] Added support for R_AARCH64_GOTPCREL32 relocation, used by Clang's experimental relative C++ ABI vtables. (be28db1)

  • [RISC-V] Added support for R_RISCV_GOT32_PCREL relocation. (f378b18)

  • [PPC32] Added support for R_PPC_DTPREL32 in non-allocatable sections. (0b20faa)

  • [SPARC64] Fixed multiple TLS optimization bugs, including incorrect register handling in R_SPARC_TLS_GD_ADD, R_SPARC_TLS_GD_LO10, and TLS_GD_CALL transformations, and fixed R_SPARC_GOTDATA_OP assuming the destination register is always %g1. (92adbb1, a16bb13, ca0b597, a88a216, 4d94410, 069f4da, e459ed5)

  • [SPARC64] Added support for emitting dynamic relocations for R_SPARC_UA64. (f55ad91)

  • [SPARC] --no-apply-dynamic-relocs is now honored for R_SPARC_UA64. (7f8c50b)

Acknowledgements

mold is an open-source project, and we accept donations via GitHub Sponsors and OpenCollective. 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:

mold 2.40.4

Choose a tag to compare

@rui314 rui314 released this 17 Aug 10:56

mold 2.40.4 is a maintenance release of the high-speed linker.

Bug Fixes and Compatibility Improvements

  • We had upgraded the bundled mimalloc memory allocator library to version 3.3.3 in the mold 2.40.3 release, but it turned out that this version of mimalloc was not stable enough. We have rolled it back, so mold is now shipped with mimalloc 2.2.2. (754949f)
  • [PPC64V1] R_PPC64_GOT16 relocation is now supported. (7e0b728)
  • [PPC64V2] R_PPC64_REL14 relocation is now supported. (d9b20a1)

mold 2.40.3

Choose a tag to compare

@rui314 rui314 released this 30 Jul 12:23

mold 2.40.3 is a maintenance release of the high-speed linker.

Bug Fixes and Compatibility Improvements

  • Starting from 2.40.1, mold wrote not a single but multiple concatenated zlib-compressed streams to debug sections if --compress-debug-sections=zlib was given. Although most tools can read such concatenated compressed data, some tools, such as LLVM's dwarfdump or Go's debug/elf package, couldn't handle them, which caused a regression. Now, mold emits a single zlib stream to each debug section. (201bc71)
  • If a command-line argument is in the form of @path/to/some/file, the linker reads the contents of the given file and interprets it as a list of command-line arguments. Such a file is called a "response file." Previously, mold could not handle partially-quoted tokens in a response file (e.g. -L"some/path" as opposed to "-Lsome/path"). Now, mold can handle such arguments. (6e8852e)
  • [PPC64] R_PPC64_GOT16* relocations are now supported. (5485fde)

mold 2.40.2

Choose a tag to compare

@rui314 rui314 released this 12 Jul 06:29

mold 2.40.2 is a maintenance release of the high-speed linker.

Bug Fixes and Compatibility Improvements

  • Fixed an issue where mold failed with a "too many open files" error when linking a very large program with LTO using Clang. (1956ae6)
  • [RISC-V] Fixed an issue in which mold failed to report a relocation overflow error. (52c698d)
  • [ARM64] mold can now create range extension thunks with displacements greater than 2^32 bytes. (47f6c28)

mold 2.40.1

Choose a tag to compare

@rui314 rui314 released this 09 Jun 04:19

mold 2.40.1 is a maintenance release of the high-speed linker. Although there are no new features in this release, it includes a few performance improvements as below.

Performance improvements

  • We've eliminated unnecessary memory zero-initialization for the --compress-debug-sections option to make debug section compression faster. With this change, mold sometimes runs faster with --compress-debug-sections than without it due to reduced file I/O. (d59c559)
  • Previously, mold used an exponential pattern-matching algorithm for glob matching, which could significantly slow down version scripts or dynamic list processing for certain glob patterns. Now, we use a linear-time algorithm that is guaranteed to run efficiently for any glob pattern. (dac20fa)

Bug Fixes and Compatibility Improvements

  • mold now reports an error if the output .dynsym refers to a section whose section index is β‰₯65280, since such a dynamic symbol is not representable in ELF. Previously, mold crashed with an assertion failure. (0d8334e)

mold 2.40.0

Choose a tag to compare

@rui314 rui314 released this 26 May 05:08

mold 2.40.0 is a new release of the high-speed linker. It includes the following new features and bug fixes.

New Features

  • mold now lays out DWARF32 debug info before DWARF64 in output debug sections to mitigate relocation overflow issues with DWARF32 when a debug info section exceeds 4 GiB. This should help people who are building extremely large executables in debug mode. (19a1bc6, 159ce3b)

    Here are the details: By default, GCC and Clang emit DWARF32 even for 64-bit code. That is, the debug info typically uses 32 bit offsets to refer to locations in other debug info sections while it uses 64 bits to represent addresses. This imposes a limitation on the largest offset DWARF32 debug info can refer to, which is 4 GiB. If the output debug section exceeds that size, the linker may report a relocation overflow error. You can instruct the compilers to emit DWARF64, which uses 64 bits for inter-debug info references, if you are building an extremely large executable. So, the proper fix for the relocation overflow issue is to build all object files with -gdwarf64. However, rebuilding all static libraries with the new compiler flag is not always feasible for various reasons. This new feature mitigates the issue by placing DWARF32 at the beginning of output debug info sections, followed by DWARF64. By doing so, relocation overflow can be prevented as long as the total size of DWARF32 remains under 4 GiB, allowing users to continue using object files compiled without -gdwarf64 in very large executables.

    Note that mold only sorts debug section contents when their size exceeds 4 GiB. Therefore, for most outputs, this mitigation doesn't change the result at all.

Bug Fixes and Compatibility Improvements

  • Fixed a regression introduced in 2.38.0 in which a thread-local variable with an unusually large alignment might not have been aligned properly. That caused mislinking of systemd when LTO was enabled (#1463). (53c1758)
  • Fixed a regression introduced in 2.38.0 in which --as-needed was ignored when creating an executable under a rare condition. (af36625)
  • Fixed an assertion failure on some targets that is triggered when an weak undefined symbol in an executable is promoted to a dynamic symbol with the -z dynamic-undefined-weak option. (0fdffad)
  • mold now ignores --dynamic-linker if -static is given. The new behavior is compatible with GNU ld. (c13ecc9)

Acknowledgements

mold is an open-source project, and we accept donations via GitHub Sponsors and OpenCollective. 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:

mold 2.39.1

Choose a tag to compare

@rui314 rui314 released this 12 May 09:10

mold 2.39.1 is a maintenance release of the high-speed linker. It includes the following bug fix:

  • Fixed a potential use-after-free issue that occurred when doing LTO (link-time optimization) with LLVM. (d0dffd5)