Releases: rui314/mold
mold 2.40.1
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-sectionsoption to make debug section compression faster. With this change, mold sometimes runs faster with--compress-debug-sectionsthan 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
.dynsymrefers 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
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-gdwarf64in 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-neededwas 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-weakoption. (0fdffad) - mold now ignores
--dynamic-linkerif-staticis 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
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)
mold 2.39.0
mold 2.39.0 is a new release of the high-speed linker. It includes the following new features and bug fixes.
New Features
-
[ARM32] Support for 32-bit big-endian ARM has been added. Although running ARM32 in big-endian mode is very rare, the processor does technically support both little- and big-endian modes, and we now support both.
There are two variants of big-endian mode for ARM32: BE32 and BE8. BE32 is now obsolete and uses big-endian format for both instructions and data. In BE8, instructions are always in little-endian (i.e., the same as little-endian ARM32), while only the data is in big-endian. mold supports only BE8 output. (157b16a)
Bug Fixes and Compatibility Improvements
-
Fixed a spurious
--no-allow-shlib-undefinederror. (3274bcb) -
[ARM][PPC] Fixed a regression introduced in 2.38.0 that mold could crash when linking a large program. (fded2d8)
-
Previously,
--default-symverdidn't set versions to symbols if the symbols were marked asglobal:in a version script. Now,--default-symvercorrectly version all symbols with the soname of the output file. (8bae43b) -
[RISC-V] Fixed an issue where mold reported an error on
R_RISCV_32when the target was 64-bit RISC-V. (564757a) -
[RISC-V] Fixed an issue where a call to an weak undefined symbol within the same shared library was mistakenly turned into an infinite loop. Now, such calls are promoted to a function call through the PLT entry. (e08e7f6)
-
Fixed an issue that mold falls into an infinite loop in a rare occasion when computing an address of the program header. (83dd353)
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.38.1
mold 2.38.1 is a maintenance release of the high-speed linker. It includes the following bug fix:
- Fixed a bug where mold could fail with a spurious
mutually-recursive .so detectederror message when building an executable. This happened if there was a circular dependency between shared libraries given to the linker (i.e., libfoo.so depends on libbar.so and vice versa). Even though libraries with circular dependencies are rare and a strong indication of a bug in the original program's library layering, the dynamic loader can load such libraries, and the linker shouldn't reject them. (21e20e0)
mold 2.38.0
mold 2.38.0 is a new release of the high-speed linker. It includes the following new features and bug fixes.
New Features
-
The
--auditand--depauditoptions are now supported for compatibility with GNU ld. (af396ad) -
Recent versions of LLVM support an alternative, experimental relocation table format called CREL. mold can now read object files containing CREL relocation tables. (c43a859)
-
[ARM32][ARM64][PPC32][PPC64] The branch instruction ranges of RISC processors are generally insufficient to support the medium code model because their instructions are typically 32 bits long, which makes it impossible to embed large immediate offsets. For example, ARM64βs branch instruction can target only PC Β± 128 MiB. If the branch target is farther than that, the linker must emit a small piece of codeβoften called a thunk or branch islandβto extend the branch range.
Previously, mold created unnecessary range extension thunks for symbols that had PLT entries. Now, mold does not create thunks unless they are truly needed. (a43f395)
Bug Fixes and Compatibility Improvements
-
Previously,
--no-allow-shlib-undefinedcould cause a segmentation fault due to an out-of-bounds array access. This has been fixed. (82affb9) -
--no-allow-shlib-undefinedis enabled by default if the output type is an executable (as opposed to a shared library) for compatibility with other linkers. (43810df) -
mold could report a spurious "duplicate symbol" error when performing LTO. This bug has been fixed. (5d24db5)
-
In rare cases involving symbol versioning, mold mistakenly filtered out necessary libraries specified with
--as-needed. This bug has been fixed. (a97a628) -
In rare cases involving symbol versioning, mold reported a spurious "undefined symbol" error. This bug has been fixed. (2d6061a)
-
If the same symbol was defined with and without the default version (e.g., if an object file defined both
fooandfoo@@VERSION), mold mistakenly hid both symbols from the dynamic symbol table instead of exporting the default one (e.g.,foo@@VERSION). This bug has been fixed. (ac6f1ec)
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:
v2.37.1
mold 2.37.0
mold 2.37.0 is a new release of the high-speed linker. It includes the following new features and bug fixes.
New Features
- If an undefined weak symbol is not resolved to a defined symbol at link time, the linker can choose whether to promote the symbol to a dynamic symbol or not. If promoted, the weak symbol has another chance to be resolved to a defined symbol at load time. Otherwise, it is resolved to address 0 at link time. Previously, mold always resolved remaining undefined weak symbols in an executable to address 0 at link time. Now, you can instruct the linker to promote them to dynamic symbols using
-z dynamic-undefined-weak. (1822e47)
Bug Fixes and Compatibility Improvements
-
[x86-64] The relocation types
R_X86_64_CODE_4_{GOTPCRELX,GOTTPOFF,GOTPC32_TLSDESC}andR_X86_64_CODE_6_GOTTPOFFare now supported. These relocations are for Intel APX (Advanced Performance Extensions), which extends the number of general-purpose registers from 16 to 32. (83152ac, a17202d) -
[ARM32] The
R_ARM_THM_JUMP8relocation type is now supported. (1fbbcec) -
[ARM32] Previously, the
.ARM.exidxsection (which contains exception-handling records) was not subject to garbage collection, even when--gc-sectionswas specified. This prevented all functions from being garbage-collected, as they were referenced by exception-handling records. Now, mold correctly garbage-collects unused.ARM.exidxrecords and functions. (16f7599) -
Previously,
--compress-debug-sectionswas ignored if--separate-debug-filewas specified. Now, mold compresses debug information sections even when they are in a separate debug file. (bab7dd1)
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.36.0
mold 2.36.0 is a new release of the high-speed linker. It includes the following new features and bug fixes.
New Features
- The
--package-metadata=<string>option has been added to embed a given string into the.note.packagesection. This option is designed for build scripts that generate binary packages, such as.rpmor.deb, to include package metadata in each executable. It simplifies the process of identifying the corresponding package for a given executable or core file. (7ddc8f4) - [ARM][PowerPC] We've improved the algorithm for creating range extension thunks to reduce memory usage and improve speed. For example, linking clang-19 for ARM64 is now ~7% faster than before. (9fc0ace)
- [RISC-V][LoongArch] We've improved the algorithm for code-shrinking linker relaxation to reduce memory usage and improve speed. For example, linking clang-19 for RISC-V is now ~4% faster than before. (3234d88)
Bug Fixes and Compatibility Improvements
- mold created a bad relocation for an IFUNC if the linker's output file type was a shared library and the symbol was exported. This bug could cause a segmentation fault of a linked program. The problem has now been fixed. (a297859)
- [RISC-V] mold could produce incorrect code as a result of code-shrinking relaxation for the
R_RISCV_HI20relocation. That type of relocation was used rarely because it is not PC-relative. That being said, if your program used the relocation, and the relocation targets were at a low address (from 0x1f800 to 0x20000), your program would crash at runtime due to the linker's bug. The issue has now been resolved. (eec3f6b) - [RISC-V][LoongArch] When the linker removed instructions from a function as a result of code-shrinking relaxation, the function symbol's size in the output file should be updated to reflect the result of relaxation, even though doing it is mostly cosmetic. mold did not do that. Now, mold sets correct sizes to output function symbols. (e6345d5)
- [LoongArch] Binaries linked with mold now work on 64 KiB page systems. Previously, only up to 16 KiB pages were supported. (2d7b6b2)
- [s390x] The s390x processor-specific ABI requires the linker to reserve the first three slots of the
.gotsection for the runtime. mold, however, reserved only two slots and used the third for itself. Even though we did not observe issues in the wild, it was a violation of the psABI. The problem has now been fixed. (dfce2fc)
Besides these changes, we've started distributing a binary package for LoongArch with this release on the release page.
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.35.1
mold 2.35.1 is a maintenance release of the high-speed linker. It includes the following bug fixes:
- mold guarantees that outputs are reproducible, meaning that if you provide the exact same set of input files and command-line options to the same version of mold, the output is assured to be byte-for-byte identical. However, there was a bug where the
--icfoption caused outputs to be indeterministic, even though all possible outputs were logically correct (#1377). This issue has now been resolved. (2a78b1b) - [RISC-V] Support for obsolete GP-relative relocations has been removed. These relocations were ratified (riscv-non-isa/riscv-elf-psabi-doc@d49e480) but then removed (riscv-non-isa/riscv-elf-psabi-doc@ad02546) from the processor-specific ABI. There are no known real-world use cases for these relocations. (04066d1)