Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Created by
brew bump
Created with
brew bump-formula-pr
.release notes
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. (19a1bc651fa43d3357d8e597140d788811ff177d, 159ce3ba6767b59a77140e34f101e595b7864a79)
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
--as-needed
was ignored when creating an executable under a rare condition. (af36625a02957c9dc717954b8fbb5c28e1d7ac0e)-z dynamic-undefined-weak
option. (0fdffad57fa12210859724ac8ca43153755f08e5)--dynamic-linker
if-static
is given. The new behavior is compatible with GNU ld. (c13ecc99ebce4686252ca56fcba0f8c67d8a90ac)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:
View the full release notes at https://github.com/rui314/mold/releases/tag/v2.40.0.