| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add newly released mold version 2.40.0 from upstream
https://github.com/rui314/mold
2.40.0
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.
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
- Fixed a regression introduced in 2.38.0 in which --as-needed was
ignored when creating an executable under a rare condition.
- 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.
- mold now ignores --dynamic-linker if -static is given. The new
behavior is compatible with GNU ld.
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add newly released mold version 2.39.1 from upstream
https://github.com/rui314/mold
2.39.1
- Fixed a potential use-after-free issue that occurred when doing LTO
(link-time optimization) with LLVM.
2.39.0
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.
Bug Fixes and Compatibility Improvements
- Fixed a spurious --no-allow-shlib-undefined error.
- [ARM][PPC] Fixed a regression introduced in 2.38.0 that mold could
crash when linking a large program.
- Previously, --default-symver didn't set versions to symbols if the
symbols were marked as global: in a version script. Now,
--default-symver correctly version all symbols with the soname of the
output file.
- [RISC-V] Fixed an issue where mold reported an error on R_RISCV_32
when the target was 64-bit RISC-V.
- [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.
- Fixed an issue that mold falls into an infinite loop in a rare
occasion when computing an address of the program header.
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add newly released mold version 2.38.1 from upstream
https://github.com/rui314/mold
2.38.1
- Fixed a bug where mold could fail with a spurious mutually-recursive
.so detected error 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.
2.38.0
New Features
- The --audit and --depaudit options are now supported for compatibility
with GNU ld.
- Recent versions of LLVM support an alternative, experimental
relocation table format called CREL. mold can now read object files
containing CREL relocation tables.
- [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.
Bug Fixes and Compatibility Improvements
- Previously, --no-allow-shlib-undefined could cause a segmentation
fault due to an out-of-bounds array access. This has been fixed.
- --no-allow-shlib-undefined is enabled by default if the output type is
an executable (as opposed to a shared library) for compatibility with
other linkers.
- mold could report a spurious "duplicate symbol" error when performing
LTO. This bug has been fixed.
- In rare cases involving symbol versioning, mold mistakenly filtered
out necessary libraries specified with --as-needed. This bug has been
fixed.
- In rare cases involving symbol versioning, mold reported a spurious
"undefined symbol" error. This bug has been fixed.
- If the same symbol was defined with and without the default version
(e.g., if an object file defined both foo and foo@@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.
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add newly released mold version 2.37.1 from upstream
https://github.com/rui314/mold
2.37.1
- Fixed a bug where mold incorrectly reported a spurious "duplicate
symbol" error when LTO was enabled. (c95476d)
2.37.0
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} and
R_X86_64_CODE_6_GOTTPOFF are 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_JUMP8 relocation type is now supported.
(1fbbcec)
- [ARM32] Previously, the .ARM.exidx section (which contains
exception-handling records) was not subject to garbage collection,
even when --gc-sections was specified. This prevented all functions
from being garbage-collected, as they were referenced by
exception-handling records. Now, mold correctly garbage-collects
unused .ARM.exidx records and functions. (16f7599)
- Previously, --compress-debug-sections was ignored if
--separate-debug-file was specified. Now, mold compresses debug
information sections even when they are in a separate debug file.
(bab7dd1)
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
|
| |
|
|
|
|
|
| |
2.36.0 is the latest version. There's no reason to keep these older ones
around.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add newly released mold version 2.36.0 from upstream
https://github.com/rui314/mold
New Features
- The --package-metadata=<string> option has been added to embed a given
string into the .note.package section. This option is designed for
build scripts that generate binary packages, such as .rpm or .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_HI20 relocation. 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 .got section 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)
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add newly released mold version 2.33.0 from upstream
https://github.com/rui314/mold
New features
- mold gained a new linker flag --separate-debug-file to bundle debug
info sections into a separate file instead of putting them into a main
output file. You can optionally specify a filename in the form of
--separate-debug-file=<filename>. By default, a debug info file is
created in the same directory as the main output file with the .dbg
extension. mold embeds the debug file's filename into the main output
file so that gdb can automatically follow the link to find debug info
when debugging the main output file.
- The main objective of this flag is to speed up the mold linker even
more. By default, mold creates a separate debug file in the background
after creating a main output file, so that you can start running the
executable as soon as possible while mold is still working on linking
its debug info sections. For example, linking clang with debug info
normally takes ~1.70s on a Threadripper 7980X machine, while it takes
only ~0.52s with --separate-debug-info. Shaving off a full second in
quick edit-rebuild-run cycles should improve programmers'
productivity. If you do not want mold to work in the background, pass
the --no-detach option. (596ffa9)
- mold now supports the --no-allow-shlib-undefined flag. If the option
is given, mold checks if all undefined symbols are resolved not only
for input object files but also for shared libraries passed to the
linker. To use the feature, you need to pass all shared libraries,
including transitively dependent ones, to the linker so that the
linker can resolve all symbols that are available at runtime.
(3001f02)
- mold gained the --dynamic-list-data flag for the sake of compatibility
with GNU ld. If the flag is given, all data symbols are exported as
dynamic symbols. (dd8d971)
- [x86-64] -z x86-64-v2, -z x86-64-v3, -z x86-64-v4 flags are supported.
(5606087)
Bug fixes and compatibility improvements
- [x86-64] Recent x86-64 processors support Intel CET to protect control
flow integrity. When the feature is enabled, the instruction that is
executed immediately after an indirect branch must be endbr64 or a CPU
fault will raise. In other words, it restricts the locations where the
control can transfer to with indirect branches. Doing that makes ROP
attacks harder to conduct.
- A problem with that is the compiler needs to conservatively emit an
endbr64 at the beginning of each global function because the compiler
doesn't know whether or not the function's address is taken in other
translation units. As a result, the resulting binary contains more
endbr64s than necessary, weakening the protection.
- mold supports the -z rewrite-endbr option to conduct a whole program
analysis and rewrite endbr64 with nop if a function's address is not
actually taken within the program. Previously, mold didn't take
section symbols into account when conducting the analysis, which
resulted in culling some endbr64s that must not be removed. Now, the
bug has been fixed. We confirmed that mold can build itself with -z
rewrite-endbr, and the resulting mold executable works fine with Intel
CET. (ed7eec5)
- mold now creates a .eh_frame section even if it's empty. (14a4b05)
- [LoongArch] The following relocations are now supported:
R_LARCH_TLS_LE_HI20_R, R_LARCH_TLS_LE_ADD_R, R_LARCH_TLS_LE_LO12_R,
R_LARCH_CALL36, R_LARCH_RELAX (36e5b4b, 98a7cff, 2c6f379)
- [LoongArch] Some relaxations that reduce the section size are now
supported. (74b359f, 121f917)
- [LoongArch] Range extension thunk support has been removed in favor of
R_LARCH_CALL36 relocations. (47c092a)
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add newly released mold version 2.32.0 from upstream
https://github.com/rui314/mold
New features
- mold supports a feature called Identical Code Folding, or ICF. As the
name suggests, ICF finds identical functions and merges them to reduce
the size of an output file. This is especially effective for
template-heavy C++ programs since templates tend to be instantiated to
the same machine code for different types. For example,
std::vector<int> is likely to be instantiated to the same code as
std::vector<unsigned>. We've made an improvement to our ICF algorithm
so that the --icf feature is ~50% faster than the previous version.
(fa8e95a)
- The -z rodynamic option is now supported for compatibility with LLVM
lld. With the option, mold places the .dynamic section into a
read-only segment. (9a233df)
Bug fixes and compatibility improvements
- Previously, mold behaved differently compared to other linkers if both
-z defs and --undefined=ignore-in-object-files were given (#1270).
Now, they override each other so that the mold's behavior is
compatible with others. (8cd85aa)
- Previously, --dependency-file mistakenly recorded response files as
dependencies (#1258). This bug has been fixed. (4281f45)
- There was a bug that mold corrupted debug info section contents when
the --relocatable option was given (#1265). This issue has been fixed.
(08b0a16)
- [PPC64] The R_PPC64_TPREL16_LO_DS relocation type is supported.
(a8cd2e8)
- [ARM64, PPC64, LoongArch] mold 2.31.0 or earlier may have failed with
an assertion failure when creating a large output file (#1224). This
issue has been resolved. (c7c8583)
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
|
|
|
Allows building the #mold linker, which can then be used in the
cross-toolchain by passing the -fuse-ld=mold to the gcc flags. It is
much faster than ld or gold.
This requires a C++20 compiler and cmake.
Initially implemented by Arnaud, and HC added configure check for cmake.
Outstanding task to validate compiler is C++20 compatible.
Signed-off-by: Arnaud Vrac <avrac@freebox.fr>
Signed-off-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
|
