Releases: rui314/mold
mold 2.40.4
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_GOT16relocation is now supported. (7e0b728) - [PPC64V2]
R_PPC64_REL14relocation is now supported. (d9b20a1)
mold 2.40.3
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=zlibwas given. Although most tools can read such concatenated compressed data, some tools, such as LLVM'sdwarfdumpor Go'sdebug/elfpackage, 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
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
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: