mirror of
https://github.com/rui314/mold.git
synced 2026-11-07 09:16:04 -10:00
Update user documentation and add installer
Copy the current README, manual, logos, and license from mold. Adapt the build and installation instructions for the Rust implementation. Add install-mold.sh to install the binary, preload library, manual, license, and linker symlinks under a configurable PREFIX with DESTDIR support.
This commit is contained in:
Rui Ueyama committed
1 parent
91164c701b
commit
39b103e44e
8 files changed
+1946
-55
No files matched your search
@@ -0,0 +1,21 @@
|
|||||||
|
MIT License
|
||||||
|
|
||||||
|
Copyright (c) 2023 Rui Ueyama
|
||||||
|
|
||||||
|
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||||
|
of this software and associated documentation files (the "Software"), to deal
|
||||||
|
in the Software without restriction, including without limitation the rights
|
||||||
|
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||||
|
copies of the Software, and to permit persons to whom the Software is
|
||||||
|
furnished to do so, subject to the following conditions:
|
||||||
|
|
||||||
|
The above copyright notice and this permission notice shall be included in all
|
||||||
|
copies or substantial portions of the Software.
|
||||||
|
|
||||||
|
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||||
|
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||||
|
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||||
|
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||||
|
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||||
|
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||||
|
SOFTWARE.
|
||||||
@@ -1,72 +1,336 @@
|
|||||||
# mold, in Rust
|
# mold: A Modern Linker
|
||||||
|
|
||||||
A port of the [mold](https://github.com/rui314/mold) linker (version
|
mold is a high-performance drop-in replacement for existing Unix linkers,
|
||||||
2.42.0) to Rust. It is a drop-in replacement for `ld`: it takes the same
|
designed to speed up builds. In our August 2026 benchmarks, it links 4.9x
|
||||||
command line, produces byte-for-byte the same kind of output, and passes
|
faster than [LLVM lld](https://lld.llvm.org) and 1.9x faster than
|
||||||
mold's own test suite.
|
[wild](https://github.com/wild-linker/wild) at the median; see
|
||||||
|
[Benchmark](#benchmark) for the full results.
|
||||||
|
|
||||||
## Building
|
mold is written by the original developer of LLVM lld, the linker that
|
||||||
|
Android, Chrome, FreeBSD, PlayStation, Nintendo Switch, and other production
|
||||||
|
systems are built with. mold started as an effort to build an even faster
|
||||||
|
linker from scratch, free of the architectural limits its author had run into
|
||||||
|
while optimizing lld. It has been in production use since 2021, and today it
|
||||||
|
is the default linker of many large open-source projects and is used
|
||||||
|
internally by many companies.
|
||||||
|
|
||||||
```
|
mold supports x86-64, i386, ARM 32/64, RISC-V 32/64, PowerPC 32/64, s390x,
|
||||||
|
LoongArch 32/64, SPARC64, m68k, and SH-4.
|
||||||
|
|
||||||
|
## Why does linking speed matter?
|
||||||
|
|
||||||
|
If you are using a compiled language such as C, C++, or Rust, a build consists
|
||||||
|
of two phases. In the first phase, a compiler compiles source files into
|
||||||
|
object files (`.o` files). In the second phase, a linker takes all object
|
||||||
|
files and combines them into a single executable or shared library file.
|
||||||
|
|
||||||
|
The second phase can be time-consuming if your build output is large. mold can
|
||||||
|
speed up this process, saving you time and preventing distractions while
|
||||||
|
waiting for a lengthy build to finish. The difference is most noticeable
|
||||||
|
during rapid debug-edit-rebuild cycles.
|
||||||
|
|
||||||
|
## Benchmark
|
||||||
|
|
||||||
|
Here is a performance comparison of lld, wild, and mold when linking nine
|
||||||
|
large programs on two machines:
|
||||||
|
|
||||||
|
- AMD Ryzen Threadripper 7980X (64 cores) running Ubuntu 24.04
|
||||||
|
- Apple M1 Ultra (16 performance cores and 4 efficiency cores) running Fedora
|
||||||
|
Asahi Remix 42; the benchmark is restricted to the performance cores
|
||||||
|
|
||||||
|
The Threadripper represents many-core workstation and server processors, and
|
||||||
|
the M1 Ultra represents high-performance desktop processors.
|
||||||
|
|
||||||
|
All three linkers were built from source in release configuration as of
|
||||||
|
2026-08-28 and ran with their default options. Times are wall-clock times as
|
||||||
|
seen by the caller, the median of three runs after a warm-up. The ARM64 rows
|
||||||
|
are the ARM64 builds of the same programs. The benchmark suite, including all
|
||||||
|
linker inputs, is available on [Zenodo](https://zenodo.org/records/21882261).
|
||||||
|
|
||||||
|
**AMD Ryzen Threadripper 7980X, debug builds**
|
||||||
|
|
||||||
|
| Program (output size) | lld | wild | mold | wild/mold | lld/mold
|
||||||
|
|-----------------------------------|--------|-------|-------|-----------|---------
|
||||||
|
| Blender 5.2 (2.46 GiB) | 4.72s | 1.98s | 0.86s | 2.3x | 5.5x
|
||||||
|
| Chromium 145 (4.51 GiB) | 16.64s | 3.98s | 1.65s | 2.4x | 10.1x
|
||||||
|
| Chromium 145 ARM64 (4.76 GiB) | 20.91s | N/A | 1.83s | N/A | 11.4x
|
||||||
|
| Clang 21 (4.19 GiB) | 6.19s | 3.71s | 1.34s | 2.8x | 4.6x
|
||||||
|
| ClickHouse 26.1 (5.58 GiB) | 6.62s | 4.40s | 0.98s | 4.5x | 6.7x
|
||||||
|
| Firefox 149 (2.37 GiB) | 5.11s | N/A | 0.78s | N/A | 6.5x
|
||||||
|
| Firefox 149 ARM64 (2.43 GiB) | 6.40s | N/A | 0.93s | N/A | 6.9x
|
||||||
|
| Godot 4.6 (1.01 GiB) | 1.77s | 1.08s | 0.46s | 2.3x | 3.8x
|
||||||
|
| LibreOffice 26.2 (0.98 GiB) | 3.46s | 1.41s | 0.44s | 3.2x | 7.9x
|
||||||
|
| PyTorch 2.9 (3.51 GiB) | 4.35s | 2.48s | 0.80s | 3.1x | 5.4x
|
||||||
|
| TensorFlow 2.21 (9.55 GiB) | 50.73s | N/A | 3.15s | N/A | 16.1x
|
||||||
|
|
||||||
|
**AMD Ryzen Threadripper 7980X, release builds**
|
||||||
|
|
||||||
|
| Program (output size) | lld | wild | mold | wild/mold | lld/mold
|
||||||
|
|-----------------------------------|-------|-------|-------|-----------|---------
|
||||||
|
| Blender 5.2 (0.24 GiB) | 0.85s | 0.30s | 0.20s | 1.5x | 4.2x
|
||||||
|
| Chromium 145 (0.58 GiB) | 6.48s | N/A | 0.64s | N/A | 10.2x
|
||||||
|
| Chromium 145 ARM64 (0.60 GiB) | 7.91s | N/A | 0.73s | N/A | 10.8x
|
||||||
|
| Clang 21 (0.21 GiB) | 0.53s | 0.23s | 0.11s | 2.2x | 5.0x
|
||||||
|
| ClickHouse 26.1 (1.23 GiB) | 3.18s | 2.07s | 0.41s | 5.0x | 7.7x
|
||||||
|
| Firefox 149 (0.22 GiB) | 1.01s | 0.41s | 0.21s | 2.0x | 4.9x
|
||||||
|
| Godot 4.6 (0.15 GiB) | 0.44s | 0.21s | 0.08s | 2.7x | 5.8x
|
||||||
|
| LibreOffice 26.2 (0.19 GiB) | 1.13s | 0.57s | 0.19s | 3.0x | 6.0x
|
||||||
|
| PyTorch 2.9 (0.31 GiB) | 0.68s | 0.32s | 0.15s | 2.2x | 4.7x
|
||||||
|
| TensorFlow 2.21 (0.73 GiB) | 9.62s | N/A | 0.70s | N/A | 13.7x
|
||||||
|
|
||||||
|
**Apple M1 Ultra, debug builds**
|
||||||
|
|
||||||
|
| Program (output size) | lld | wild | mold | wild/mold | lld/mold
|
||||||
|
|-----------------------------------|--------|-------|-------|-----------|---------
|
||||||
|
| Blender 5.2 (2.46 GiB) | 3.21s | 1.81s | 1.56s | 1.2x | 2.1x
|
||||||
|
| Chromium 145 (4.51 GiB) | 9.54s | 3.49s | 2.22s | 1.6x | 4.3x
|
||||||
|
| Chromium 145 ARM64 (4.76 GiB) | 12.67s | N/A | 2.31s | N/A | 5.5x
|
||||||
|
| Clang 21 (4.19 GiB) | 4.40s | 2.78s | 2.96s | 0.9x | 1.5x
|
||||||
|
| ClickHouse 26.1 (5.58 GiB) | 4.92s | 3.50s | 1.71s | 2.1x | 2.9x
|
||||||
|
| Firefox 149 (2.37 GiB) | 3.21s | N/A | 1.12s | N/A | 2.9x
|
||||||
|
| Firefox 149 ARM64 (2.43 GiB) | 4.13s | N/A | 1.12s | N/A | 3.7x
|
||||||
|
| Godot 4.6 (1.01 GiB) | 1.12s | 0.81s | 0.62s | 1.3x | 1.8x
|
||||||
|
| LibreOffice 26.2 (0.98 GiB) | 2.08s | 0.94s | 0.63s | 1.5x | 3.3x
|
||||||
|
| PyTorch 2.9 (3.51 GiB) | 3.07s | 2.10s | 1.45s | 1.4x | 2.1x
|
||||||
|
| TensorFlow 2.21 (9.55 GiB) | 43.68s | N/A | 4.43s | N/A | 9.9x
|
||||||
|
|
||||||
|
**Apple M1 Ultra, release builds**
|
||||||
|
|
||||||
|
| Program (output size) | lld | wild | mold | wild/mold | lld/mold
|
||||||
|
|-----------------------------------|-------|-------|-------|-----------|---------
|
||||||
|
| Blender 5.2 (0.24 GiB) | 0.56s | 0.20s | 0.25s | 0.8x | 2.3x
|
||||||
|
| Chromium 145 (0.58 GiB) | 4.25s | N/A | 0.78s | N/A | 5.5x
|
||||||
|
| Chromium 145 ARM64 (0.60 GiB) | 5.17s | N/A | 0.91s | N/A | 5.7x
|
||||||
|
| Clang 21 (0.21 GiB) | 0.30s | 0.15s | 0.14s | 1.0x | 2.1x
|
||||||
|
| ClickHouse 26.1 (1.23 GiB) | 1.94s | 0.95s | 0.55s | 1.7x | 3.5x
|
||||||
|
| Firefox 149 (0.22 GiB) | 0.56s | 0.23s | 0.20s | 1.1x | 2.7x
|
||||||
|
| Godot 4.6 (0.15 GiB) | 0.26s | 0.11s | 0.11s | 1.0x | 2.3x
|
||||||
|
| LibreOffice 26.2 (0.19 GiB) | 0.62s | 0.30s | 0.23s | 1.3x | 2.7x
|
||||||
|
| PyTorch 2.9 (0.31 GiB) | 0.43s | 0.22s | 0.17s | 1.3x | 2.5x
|
||||||
|
| TensorFlow 2.21 (0.73 GiB) | 8.07s | N/A | 0.68s | N/A | 11.9x
|
||||||
|
|
||||||
|
N/A indicates that the linker cannot link that program. wild's Chromium
|
||||||
|
release links are also marked N/A because wild does not implement `--icf=all`
|
||||||
|
and links without identical code folding.
|
||||||
|
|
||||||
|
## Why is mold so fast?
|
||||||
|
|
||||||
|
mold owes its speed to pervasive parallelism and to efficient data structures
|
||||||
|
and algorithms. For details, read our paper "mold: A Massively Parallel
|
||||||
|
Linker" (ASPLOS 2027), available at https://arxiv.org/abs/2608.23228.
|
||||||
|
|
||||||
|
## Installation
|
||||||
|
|
||||||
|
Binary packages for the following systems are currently available:
|
||||||
|
|
||||||
|
[](https://repology.org/project/mold/versions)
|
||||||
|
|
||||||
|
Prebuilt binaries for Linux on x86-64, ARM64, ARM32, RISC-V, PPC64LE, s390x,
|
||||||
|
and LoongArch are also attached to each
|
||||||
|
[GitHub release](https://github.com/rui314/mold/releases).
|
||||||
|
|
||||||
|
## How to Build
|
||||||
|
|
||||||
|
mold is written in Rust and built with Cargo. You need Git, a stable Rust
|
||||||
|
toolchain, and a C compiler.
|
||||||
|
|
||||||
|
### Install Dependencies
|
||||||
|
|
||||||
|
Install the stable Rust toolchain with [rustup](https://rustup.rs/) and make
|
||||||
|
sure `cc` is available in `PATH`.
|
||||||
|
|
||||||
|
### Compile mold
|
||||||
|
|
||||||
|
```shell
|
||||||
|
git clone --branch stable https://github.com/rui314/mold.git
|
||||||
|
cd mold
|
||||||
cargo build --release
|
cargo build --release
|
||||||
```
|
```
|
||||||
|
|
||||||
The binary is `target/release/mold`. It answers to `ld` as well, so a
|
The executable and its companion preload library are
|
||||||
symlink named `ld` in a directory passed to the compiler with `-B` makes
|
`target/release/mold` and `target/release/mold-wrapper.so`.
|
||||||
GCC and Clang use it. The build also compiles three C parts: mimalloc from
|
|
||||||
the pinned `mimalloc_rust` dependency, used as the global allocator,
|
|
||||||
`mold-wrapper.so`, the preload library behind `mold -run`, and the variadic
|
|
||||||
adapter the LTO plugin API needs.
|
|
||||||
|
|
||||||
The linker is generic over the target, and instantiating it for all
|
### Install mold
|
||||||
twenty targets in one crate keeps the compiler on a single core for
|
|
||||||
minutes. So the crate is a workspace: `mold` is the generic library, each
|
|
||||||
`targets/<name>` crate instantiates it for one target, and `cli` is the
|
|
||||||
executable, with a feature per target. Building the executable alone for
|
|
||||||
one target is much faster:
|
|
||||||
|
|
||||||
```
|
Run `sudo ./install-mold.sh` to install mold under `/usr/local`. To install it
|
||||||
cargo build --release -p mold-cli --no-default-features --features x86_64
|
under a different prefix, set `PREFIX`, as in
|
||||||
|
`sudo PREFIX=/usr ./install-mold.sh`.
|
||||||
|
|
||||||
|
You can also run `target/release/mold` directly without installing it.
|
||||||
|
|
||||||
|
## How to use
|
||||||
|
|
||||||
|
<details><summary>A classic way to use mold</summary>
|
||||||
|
|
||||||
|
On Unix, the linker command (usually `/usr/bin/ld`) is indirectly invoked by
|
||||||
|
the compiler driver (typically `cc`, `gcc`, or `clang`), which is in turn
|
||||||
|
indirectly invoked by `make` or other build system commands.
|
||||||
|
|
||||||
|
If you can specify an additional command line option for your compiler driver
|
||||||
|
by modifying the build system's config files, add one of the following flags
|
||||||
|
to use mold instead of `/usr/bin/ld`:
|
||||||
|
|
||||||
|
- For Clang: pass `-fuse-ld=mold`
|
||||||
|
|
||||||
|
- For GCC 12.1.0 or later: pass `-fuse-ld=mold`
|
||||||
|
|
||||||
|
- For GCC before 12.1.0: the `-fuse-ld` option does not accept `mold` as a
|
||||||
|
valid argument, so you need to use the `-B` option instead. The `-B` option
|
||||||
|
tells GCC where to look for external commands like `ld`.
|
||||||
|
|
||||||
|
If you installed mold using the script above, there is a directory named
|
||||||
|
`/usr/local/libexec/mold`, and the `ld` command there is a symlink to mold.
|
||||||
|
Pass `-B/usr/local/libexec/mold` to GCC. If you installed under another
|
||||||
|
prefix, use that prefix instead.
|
||||||
|
|
||||||
|
If you haven't installed `ld.mold` to any `$PATH`, you can still pass
|
||||||
|
`-fuse-ld=/absolute/path/to/mold` to clang to use mold. However, GCC does not
|
||||||
|
accept an absolute path as an argument for `-fuse-ld`.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details><summary>If you are using Rust</summary>
|
||||||
|
|
||||||
|
Create `.cargo/config.toml` in your project directory with the following:
|
||||||
|
|
||||||
|
```toml
|
||||||
|
[target.'cfg(target_os = "linux")']
|
||||||
|
linker = "clang"
|
||||||
|
rustflags = ["-C", "link-arg=-fuse-ld=/path/to/mold"]
|
||||||
```
|
```
|
||||||
|
|
||||||
## Testing
|
where `/path/to/mold` is an absolute path to the mold executable. In the
|
||||||
|
example above, we use `clang` as a linker driver since it always accepts the
|
||||||
|
`-fuse-ld` option. If your GCC is recent enough to recognize the option, you
|
||||||
|
may be able to remove the `linker = "clang"` line.
|
||||||
|
|
||||||
The tests are mold's own shell scripts, copied unchanged into `tests/cases/`.
|
```toml
|
||||||
`cargo test` runs the Rust unit tests and the complete available shell-test
|
[target.'cfg(target_os = "linux")']
|
||||||
matrix in parallel:
|
rustflags = ["-C", "link-arg=-fuse-ld=mold"]
|
||||||
|
|
||||||
```
|
|
||||||
cargo test
|
|
||||||
cargo test tls-
|
|
||||||
cargo test -- --test-threads 8
|
|
||||||
cargo test -p mold-cli --test integration -- --native
|
|
||||||
cargo test -p mold-cli --test integration -- \
|
|
||||||
--triple aarch64-linux-gnu
|
|
||||||
```
|
```
|
||||||
|
|
||||||
The last two forms select only the native target or one cross target. Logs go
|
If you want to use mold for all projects, add the above snippet to
|
||||||
to `target/debug/mold-test/out/test/results/<machine>/` (or the corresponding
|
`~/.cargo/config.toml`.
|
||||||
Cargo profile directory). As in mold's CMake setup, a target runs the generic
|
|
||||||
tests plus the ones prefixed with its architecture; tests whose prerequisites
|
|
||||||
are missing skip themselves.
|
|
||||||
|
|
||||||
## Targets
|
</details>
|
||||||
|
|
||||||
x86-64, i386, ARM64 (both byte orders), ARM32 (little-endian and BE8),
|
<details><summary>If you are using Nim</summary>
|
||||||
RISC-V (32- and 64-bit, both byte orders), PowerPC (32-bit, and 64-bit
|
|
||||||
ELFv1 and ELFv2), s390x, SPARC64, m68k, SH-4 (both byte orders) and
|
|
||||||
LoongArch (32- and 64-bit). Every target for which a cross toolchain was
|
|
||||||
available passes its full suite: x86-64, i386, ARM64, ARM32, RISC-V 64,
|
|
||||||
PowerPC 32/64/64LE, s390x, SPARC64, m68k and SH-4.
|
|
||||||
|
|
||||||
## Layout
|
Create `config.nims` in your project directory with the following:
|
||||||
|
|
||||||
| Module | What it holds |
|
```nim
|
||||||
| --- | --- |
|
when findExe("mold").len > 0 and defined(linux):
|
||||||
| `driver` | The link in order: reading inputs, resolving symbols, laying out the output, writing it |
|
switch("passL", "-fuse-ld=mold")
|
||||||
| `args`, `linker_script` | Command line and script parsing |
|
```
|
||||||
| `input_files`, `input_sections`, `symbol` | Object files, shared libraries, their sections and symbols |
|
|
||||||
| `passes`, `gc_sections`, `icf`, `relax`, `thunks` | The link's passes, from symbol resolution to range extension thunks |
|
where `mold` must be included in the `PATH` environment variable. In this
|
||||||
| `chunks` | Everything that ends up in the output: output sections and the synthesized ones (`.got`, `.plt`, `.dynamic`, `.eh_frame`, ...) |
|
example, `gcc` is used as the linker driver. Use the `-fuse-ld` option if your
|
||||||
| `arch` | One module per target: relocation scanning and application, PLT stubs, thunks, relaxation |
|
GCC is recent enough to recognize this option.
|
||||||
| `lto`, `gdb_index`, `output_file`, `elf`, `util` | The LTO plugin bridge, `.gdb_index` generation, output files, the ELF format and helpers |
|
|
||||||
|
If you want to use mold for all projects, add the above snippet to
|
||||||
|
`~/.config/config.nims`.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details><summary>If you are using Conan package manager</summary>
|
||||||
|
|
||||||
|
You can configure [Conan](https://github.com/conan-io) to download the latest
|
||||||
|
version of `mold` and use it as the linker when building your dependencies and
|
||||||
|
projects from source. Please see the instructions [here](https://conan.io/center/recipes/mold).
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details><summary>mold -run</summary>
|
||||||
|
|
||||||
|
It is sometimes very hard to pass an appropriate command line option to `cc`
|
||||||
|
to specify an alternative linker. To address this situation, mold has a
|
||||||
|
feature to intercept all invocations of `ld`, `ld.bfd`, `ld.lld`, or `ld.gold`
|
||||||
|
and redirect them to itself. To use this feature, run `make` (or another build
|
||||||
|
command) as a subcommand of mold as follows:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
mold -run make <make-options-if-any>
|
||||||
|
```
|
||||||
|
|
||||||
|
Internally, mold invokes a given command with the `LD_PRELOAD` environment
|
||||||
|
variable set to its companion shared object file. The shared object file
|
||||||
|
intercepts all function calls to `exec(3)`-family functions to replace
|
||||||
|
`argv[0]` with `mold` if it is `ld`, `ld.bfd`, `ld.gold`, or `ld.lld`.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details><summary>GitHub Actions</summary>
|
||||||
|
|
||||||
|
You can use our [setup-mold](https://github.com/rui314/setup-mold) GitHub
|
||||||
|
Action to speed up GitHub-hosted continuous builds. Although GitHub Actions
|
||||||
|
run on a 4 core machine, mold is still significantly faster than the default
|
||||||
|
GNU linker, especially when linking large programs.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details><summary>Verify that you are using mold</summary>
|
||||||
|
|
||||||
|
mold leaves its identification string in the `.comment` section of an output
|
||||||
|
file. You can print it out to verify that you are actually using mold.
|
||||||
|
|
||||||
|
```shell
|
||||||
|
$ readelf -p .comment <executable-file>
|
||||||
|
|
||||||
|
String dump of section '.comment':
|
||||||
|
[ 0] GCC: (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0
|
||||||
|
[ 2b] mold 9a1679b47d9b22012ec7dfbda97c8983956716f7
|
||||||
|
```
|
||||||
|
|
||||||
|
If `mold` is present in the `.comment` section, the file was created by mold.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
<details><summary>Online manual</summary>
|
||||||
|
|
||||||
|
Since mold is a drop-in replacement, you should be able to use it without
|
||||||
|
reading its manual. However, if you need it, [mold's man page](docs/mold.md)
|
||||||
|
is available online. You can read the same manual by running `man mold`.
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
## Stability
|
||||||
|
|
||||||
|
mold has been developed in the open since 2020 and has more than 140
|
||||||
|
contributors. Its test suite, which covers every linker feature, runs in CI for
|
||||||
|
all supported target CPU architectures, natively or under QEMU, and under ASAN
|
||||||
|
and TSAN. Before each release, we try to build all of Gentoo Linux's roughly
|
||||||
|
19,000 packages with mold, using GNU ld as a control, to find regressions before
|
||||||
|
they reach a release.
|
||||||
|
|
||||||
|
## Sponsors
|
||||||
|
|
||||||
|
mold is free to use, but keeping it maintained is continuous work: supporting
|
||||||
|
new architectures and toolchain features, keeping up with the projects that
|
||||||
|
depend on it, and making it faster. That work is funded by sponsors. If mold
|
||||||
|
saves you or your company time, please consider becoming a
|
||||||
|
[GitHub sponsor](https://github.com/sponsors/rui314).
|
||||||
|
|
||||||
|
We thank everyone who sponsors the project. In particular, we'd like to
|
||||||
|
acknowledge the following people and organizations who have sponsored
|
||||||
|
$128/month or more:
|
||||||
|
|
||||||
|
### Corporate sponsors
|
||||||
|
|
||||||
|
<a href="https://mercury.com"><img src="docs/mercury-logo.png" align=center height=120 width=400 alt=Mercury></a>
|
||||||
|
|
||||||
|
<a href="https://cybozu-global.com"><img src="docs/cyboze-logo.png" align=center height=120 width=133 alt=Cybozu></a>
|
||||||
|
|
||||||
|
<a href="https://www.emergetools.com"><img src="docs/emerge-tools-logo.png" align=center height=120 width=240 alt="Emerge Tools"></a><br>
|
||||||
|
|
||||||
|
- [G-Research](https://www.gresearch.co.uk)
|
||||||
|
- [Signal Slot Inc.](https://github.com/signal-slot)
|
||||||
|
- [GlareDB](https://github.com/GlareDB)
|
||||||
|
|
||||||
|
### Individual sponsors
|
||||||
|
|
||||||
|
- [Wei Wu](https://github.com/lazyparser)
|
||||||
|
- [kyle-elliott](https://github.com/kyle-elliott)
|
||||||
|
- [Bryant Biggs](https://github.com/bryantbiggs)
|
||||||
|
- [kraptor23](https://github.com/kraptor23)
|
||||||
|
- [Jinkyu Yi](https://github.com/jincreator)
|
||||||
|
- [Pedro Navarro](https://github.com/pedronavf)
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 51 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
+581
@@ -0,0 +1,581 @@
|
|||||||
|
.\" generated with Ronn-NG/v0.9.1
|
||||||
|
.\" http://github.com/apjanke/ronn-ng/tree/0.9.1
|
||||||
|
.TH "MOLD" "1" "August 2026" ""
|
||||||
|
.SH "NAME"
|
||||||
|
\fBmold\fR \- a modern linker
|
||||||
|
.SH "SYNOPSIS"
|
||||||
|
\fBmold\fR [\fIoption\fR\|\.\|\.\|\.] \fIfile\fR\|\.\|\.\|\.
|
||||||
|
.SH "DESCRIPTION"
|
||||||
|
\fBmold\fR is a faster drop\-in replacement for the default GNU ld(1)\.
|
||||||
|
.SS "How to use"
|
||||||
|
See \fIhttps://github\.com/rui314/mold#how\-to\-use\fR\.
|
||||||
|
.SS "Compatibility"
|
||||||
|
\fBmold\fR is designed to be a drop\-in replacement for the GNU linkers for linking user\-land programs\. If your user\-land program cannot be built due to missing command\-line options, please file a bug at \fIhttps://github\.com/rui314/mold/issues\fR\.
|
||||||
|
.P
|
||||||
|
\fBmold\fR supports a very limited set of linker script features, which is just sufficient to read \fB/usr/lib/x86_64\-linux\-gnu/libc\.so\fR on Linux systems (on Linux, that file is contrary to its name not a shared library but an ASCII linker script that loads a real \fBlibc\.so\fR file\.)
|
||||||
|
.P
|
||||||
|
Beyond that, we have no plan to support any additional linker script features\. The linker script is an ad\-hoc, over\-designed, complex language which we believe needs to be replaced by a simpler mechanism\. We have a plan to add a replacement for the linker script to \fBmold\fR instead\.
|
||||||
|
.SS "Archive symbol resolution"
|
||||||
|
Traditionally, Unix linkers are sensitive to the order in which input files appear on the command line\. They process input files from the first (leftmost) file to the last (rightmost) file one\-by\-one\. While reading input files, they maintain sets of defined and undefined symbols\. When visiting an archive file (\fB\.a\fR files), they pull out object files to resolve as many undefined symbols as possible and move on to the next input file\. Object files that weren't pulled out will never have a chance for a second look\.
|
||||||
|
.P
|
||||||
|
Due to this behavior, you usually have to add archive files at the end of a command line, so that when a linker reaches archive files, it knows what symbols remain as undefined\.
|
||||||
|
.P
|
||||||
|
If you put archive files at the beginning of a command line, a linker doesn't have any undefined symbols, and thus no object files will be pulled out from archives\. You can change the processing order by using the \fB\-\-start\-group\fR and \fB\-\-end\-group\fR options, though they make a linker slower\.
|
||||||
|
.P
|
||||||
|
\fBmold\fR, as well as the LLVM lld(1) linker, takes a different approach\. They remember which symbols can be resolved from archive files instead of forgetting them after processing each archive\. Therefore, \fBmold\fR and lld(1) can "go back" in a command line to pull out object files from archives if they are needed to resolve remaining undefined symbols\. They are not sensitive to the input file order\.
|
||||||
|
.P
|
||||||
|
\fB\-\-start\-group\fR and \fB\-\-end\-group\fR are still accepted by \fBmold\fR and lld(1) for compatibility with traditional linkers, but they are silently ignored\.
|
||||||
|
.SS "Dynamic symbol resolution"
|
||||||
|
Some Unix linker features are difficult to understand without comprehending the semantics of dynamic symbol resolution\. Therefore, even though it's not specific to \fBmold\fR, we'll explain it here\.
|
||||||
|
.P
|
||||||
|
We use "ELF module" or just "module" as a collective term to refer to an executable or a shared library file in the ELF format\.
|
||||||
|
.P
|
||||||
|
An ELF module may have lists of imported symbols and exported symbols, as well as a list of shared library names from which imported symbols should be imported\. The point is that imported symbols are not bound to any specific shared library until runtime\.
|
||||||
|
.P
|
||||||
|
Here is how the Unix dynamic linker resolves dynamic symbols\. Upon the start of an ELF program, the dynamic linker constructs a list of ELF modules which, as a whole, consist of a complete program\. The executable file is always at the beginning of the list followed by its dependent shared libraries\. An imported symbol is searched from the beginning of the list to the end\. If two or more modules define the same symbol, the one that appears first in the list takes precedence over the others\.
|
||||||
|
.P
|
||||||
|
This Unix semantics are contrary to systems such as Windows that have a two\-level namespace for dynamic symbols\. On Windows, for example, dynamic symbols are represented as a tuple of (\fBsymbol\-name\fR, \fBshared\-library\-name\fR), so that each dynamic symbol is guaranteed to be resolved from some specific library\.
|
||||||
|
.P
|
||||||
|
Typically, an ELF module that exports a symbol also imports the same symbol\. Such a symbol is usually resolved to itself, but that's not the case if a module that appears before it in the symbol search list provides another definition of the same symbol\.
|
||||||
|
.P
|
||||||
|
Let's take \fBmalloc\fR as an example\. Assume that you define your version of \fBmalloc\fR in your main executable file\. Then, all \fBmalloc\fR calls from any module are resolved to your function instead of the one in libc, because the executable is always at the beginning of the dynamic symbol search list\. Note that even \fBmalloc\fR calls within libc are resolved to your definition since libc exports and imports \fBmalloc\fR\. Therefore, by defining \fBmalloc\fR yourself, you can overwrite a library function, and the \fBmalloc\fR in libc becomes dead code\.
|
||||||
|
.P
|
||||||
|
These Unix semantics are tricky and sometimes considered harmful\. For example, assume that you accidentally define \fBatoi\fR as a global function in your executable that behaves completely differently from the one in the C standard\. Then, all \fBatoi\fR function calls from any modules (even function calls within libc) are redirected to your function instead of the one in libc, which will very likely cause a problem\. That is a somewhat surprising consequence for an accidental name conflict\. On the other hand, this semantic is sometimes useful because it allows users to override library functions without rebuilding modules containing them\.
|
||||||
|
.P
|
||||||
|
Whether good or bad, you should keep these semantics in mind to understand Unix linkers' behaviors\.
|
||||||
|
.SS "Build reproducibility"
|
||||||
|
\fBmold\fR's output is deterministic\. That is, if you pass the same object files and the same command\-line options to the same version of \fBmold\fR, it is guaranteed that \fBmold\fR produces the bit\-for\-bit identical output\. The linker's internal randomness, such as the timing of thread scheduling or iteration orders of hash tables, doesn't affect the output\.
|
||||||
|
.P
|
||||||
|
\fBmold\fR does not have any host\-specific default settings\. This is contrary to the GNU linkers, for which some configurable values, such as system\-dependent library search paths, are hard\-coded\. \fBmold\fR depends only on its command\-line arguments\.
|
||||||
|
.SH "OPTION NOTATIONS"
|
||||||
|
Multi\-letter long options may precede either a single dash or double dashes, except for those starting with the letter "o"\. For historical reasons, long options beginning with "o" must precede double dashes\.
|
||||||
|
.P
|
||||||
|
For example, you can spell \fB\-\-as\-needed\fR as \fB\-as\-needed\fR, but \fB\-\-omagic\fR must not be spelled as \fB\-omagic\fR\. \fB\-omagic\fR will be interpreted not as \fB\-\-omagic\fR but as \fB\-o magic\fR\.
|
||||||
|
.SH "MOLD\-SPECIFIC OPTIONS"
|
||||||
|
.TP
|
||||||
|
\fB\-\-chroot\fR=\fIdir\fR
|
||||||
|
Set \fIdir\fR as the root directory\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-color\-diagnostics\fR=[ \fIauto\fR | \fIalways\fR | \fInever\fR ]
|
||||||
|
Show diagnostic messages in color using ANSI escape sequences\. \fBauto\fR means that \fBmold\fR prints out messages in color only if the standard output is connected to a TTY\. Default is \fBauto\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-color\-diagnostics\fR
|
||||||
|
Synonym for \fB\-\-color\-diagnostics=auto\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-no\-color\-diagnostics\fR
|
||||||
|
Synonym for \fB\-\-color\-diagnostics=never\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-detach\fR, \fB\-\-no\-detach\fR
|
||||||
|
Permit or do not permit mold to create a debug info file in the background\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-fork\fR, \fB\-\-no\-fork\fR
|
||||||
|
Spawn a child process and let it do the actual linking\. When linking a large program, the OS kernel can take a few hundred milliseconds to terminate a \fBmold\fR process\. \fB\-\-fork\fR hides that latency\. By default, it does fork\.
|
||||||
|
.IP
|
||||||
|
Note that \fB\-\-fork\fR also hides the resource usage statistics reported by time(2), since it doesn't call waitpid(2) on the child process\. If you need those statistics, pass \fB\-\-no\-fork\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-perf\fR
|
||||||
|
Print performance statistics\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-print\-dependencies\fR
|
||||||
|
Print out dependency information for input files\.
|
||||||
|
.IP
|
||||||
|
Each line of the output for this option shows which file depends on which file to use a specific symbol\. This option is useful for debugging why some object file in a static archive got linked or why some shared library is kept in an output file's dependency list even with \fB\-\-as\-needed\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-relocatable\-merge\-sections\fR
|
||||||
|
By default, \fBmold\fR doesn't merge input sections by name when merging input object files into a single output object file for \fB\-r\fR\. For example, \fB\.text\.foo\fR and \fB\.text\.bar\fR aren't merged for \fB\-r\fR even though they are merged into \fB\.text\fR based on the default section merging rules\.
|
||||||
|
.IP
|
||||||
|
This option changes the behavior so that \fBmold\fR merges input sections by name by the default section merging rules\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-repro\fR
|
||||||
|
Archive input files, as well as a text file containing command line options, in a tar file so that you can run \fBmold\fR with the exact same inputs again\. This is useful for reporting a bug with a reproducer\. The output filename is \fBpath/to/output\.tar\fR, where \fBpath/to/output\fR is an output filename specified by \fB\-o\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-reverse\-sections\fR
|
||||||
|
Reverse the order of input sections before assigning them the offsets in the output file\.
|
||||||
|
.IP
|
||||||
|
This option is useful for finding bugs that depend on the initialization order of global objects\. In C++, constructors of global objects in a single source file are guaranteed to be executed in the source order, but there's no such guarantee across compilation units\. Usually, constructors are executed in the order given to the linker, but depending on it is a mistake\.
|
||||||
|
.IP
|
||||||
|
By reversing the order of input sections using \fB\-\-reverse\-sections\fR, you can easily test that your program works in the reversed initialization order\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-run\fR \fIcommand\fR \fIarg\fR\|\.\|\.\|\.
|
||||||
|
Run \fIcommand\fR with \fBmold\fR as \fB/usr/bin/ld\fR\. Specifically, \fBmold\fR runs a given command with the \fBLD_PRELOAD\fR environment set to intercept exec(3) family functions and replaces \fBargv[0]\fR with itself if it is \fBld\fR, \fBld\.gold\fR, or \fBld\.lld\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-separate\-debug\-file\fR, \fB\-\-separate\-debug\-file\fR=\fIfile\fR
|
||||||
|
Bundle debug info sections into a separate file instead of embedding them in an output executable or a shared library\. mold creates a debug info file in the background by default, so that you can start running your executable as soon as possible\.
|
||||||
|
.IP
|
||||||
|
By default, the debug info file is created in the same directory as is the output file, with the \fB\.dbg\fR file extension\. That filename is embedded into the output file so that \fBgdb\fR can automatically find the debug info file for the output file\. For more info about gdb features related to separate debug files, see \fIhttps://sourceware\.org/gdb/current/onlinedocs/gdb\.html/Separate\-Debug\-Files\.html\fR\.
|
||||||
|
.IP
|
||||||
|
mold holds a file lock with flock(2) while creating a debug info file in the background\.
|
||||||
|
.IP
|
||||||
|
If you don't want to create a debug info file in the background, pass the \fB\-\-no\-detach\fR option\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-shuffle\-sections\fR, \fB\-\-shuffle\-sections\fR=\fInumber\fR
|
||||||
|
Randomize the output by shuffling the order of input sections before assigning them the offsets in the output file\. If a \fInumber\fR is given, it's used as a seed for the random number generator, so that the linker produces the same output for the same seed\. If no seed is given, a random number is used as a seed\.
|
||||||
|
.IP
|
||||||
|
This option is useful for benchmarking\. Modern CPUs are sensitive to a program's memory layout\. A seemingly benign change in program layout, such as a small size increase of a function in the middle of a program, can affect the program's performance\. Therefore, even if you write new code and get a good benchmark result, it is hard to say whether the new code improves the program's performance; it is possible that the new memory layout happens to perform better\.
|
||||||
|
.IP
|
||||||
|
By running a benchmark multiple times with randomized memory layouts using \fB\-\-shuffle\-sections\fR, you can isolate your program's real performance number from the randomness caused by memory layout changes\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-spare\-program\-headers\fR=\fInumber\fR
|
||||||
|
Append the given number of \fBPT_NULL\fR entries to the end of the program header, so that post\-link processing tools can easily add new segments by overwriting the null entries\.
|
||||||
|
.IP
|
||||||
|
Note that ELF requires all \fBPT_LOAD\fR segments to be sorted by \fBp_vaddr\fR\. Therefore, if you add a new LOAD segment, you may need to sort the entire program header\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-stats\fR
|
||||||
|
Print input statistics\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-thread\-count\fR=\fIcount\fR
|
||||||
|
Use \fIcount\fR number of threads\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-threads\fR, \fB\-\-no\-threads\fR
|
||||||
|
Use multiple threads\. By default, \fBmold\fR uses as many threads as the number of cores or 32, whichever is smaller\. The reason it is capped at 32 is because \fBmold\fR doesn't scale well beyond that point\. To use only one thread, pass \fB\-\-no\-threads\fR or \fB\-\-thread\-count=1\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-quick\-exit\fR, \fB\-\-no\-quick\-exit\fR
|
||||||
|
Use or do not use \fBquick_exit\fR to exit\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-zero\-to\-bss\fR
|
||||||
|
Convert all\-zero data sections into BSS\.
|
||||||
|
.IP
|
||||||
|
When this option is enabled, \fBmold\fR scans input data sections that are not of type \fBSHT_NOBITS\fR and checks whether their contents consist solely of zero bytes\. Such sections are then converted into BSS (\fBSHT_NOBITS\fR) sections\. This reduces the size of the output file, since BSS sections occupy no space in the file image\.
|
||||||
|
.IP
|
||||||
|
This behavior is especially useful for user\-defined sections created with \fB__attribute__((section("\.sectname")))\fR that contain uninitialized global variables\. GCC and Clang do not automatically mark such sections as BSS even if their contents are entirely zero, and instead emit them as regular data sections\.
|
||||||
|
.IP
|
||||||
|
For example, consider \fB__attribute__((section("\.sectname"))) int vec[256];\fR\.
|
||||||
|
.IP
|
||||||
|
By default, this results in a \fB\.sectname\fR section of type \fBSHT_PROGBITS\fR filled with zeros\. With \fB\-\-zero\-to\-bss\fR, the linker will recognize it as empty data and convert it to a \fBSHT_NOBITS\fR section, reducing the output file size without changing runtime semantics\.
|
||||||
|
.TP
|
||||||
|
\fB\-z rewrite\-endbr\fR, \fB\-z norewrite\-endbr\fR
|
||||||
|
As a security measure, some CPU instruction sets have recently gained a feature to protect control flow integrity by disallowing indirect branches by default\. If the feature is enabled, the instruction that is executed immediately after an indirect branch must be an branch target marker instruction, or a CPU\-level fault will raise\. The marker instruction is also known as "landing pad" instruction, to which indirect branches can land\. This feature makes ROP attacks harder to conduct\.
|
||||||
|
.IP
|
||||||
|
To use the feature, a function whose pointer is taken needs to begin with a landing pad because a function call via a function pointer is compiled to an indirect branch\. On the other hand, if a function is called only directly (i\.e\. referred to only by \fIdirect\fR branch instructions), it doesn't have to begin with it\.
|
||||||
|
.IP
|
||||||
|
By default, the compiler always emits a landing pad at the beginning of each global function because it doesn't know whether or not the function's pointer is taken in another translation unit\. As a result, the resulting binary has more attack surface than necessary\.
|
||||||
|
.IP
|
||||||
|
If \fB\-\-rewrite\-endbr\fR is given, mold conducts a whole program analysis to identify functions whose addresses are actually taken and rewrites landing pads with no\-ops for non\-address\-taken functions, reducing the attack surface\.
|
||||||
|
.IP
|
||||||
|
This feature is currently available only on x86\-64\.
|
||||||
|
.SH "GNU\-COMPATIBLE OPTIONS"
|
||||||
|
.TP
|
||||||
|
\fB\-\-help\fR
|
||||||
|
Report usage information to stdout and exit\.
|
||||||
|
.TP
|
||||||
|
\fB\-v\fR, \fB\-\-version\fR
|
||||||
|
Report version information to stdout\.
|
||||||
|
.TP
|
||||||
|
\fB\-V\fR
|
||||||
|
Report version and target information to stdout\.
|
||||||
|
.TP
|
||||||
|
\fB\-E\fR, \fB\-\-export\-dynamic\fR, \fB\-\-no\-export\-dynamic\fR
|
||||||
|
When creating an executable, using the \fB\-E\fR option causes all global symbols to be put into the dynamic symbol table, so that the symbols are visible from other ELF modules at runtime\.
|
||||||
|
.IP
|
||||||
|
By default, or if \fB\-\-no\-export\-dynamic\fR is given, only symbols that are referenced by DSOs at link\-time are exported from an executable\.
|
||||||
|
.TP
|
||||||
|
\fB\-F\fR \fIlibname\fR, \fB\-\-filter\fR=\fIlibname\fR
|
||||||
|
Set the \fBDT_FILTER\fR dynamic section field to \fIlibname\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-I\fR \fIfile\fR, \fB\-\-dynamic\-linker\fR=\fIfile\fR, \fB\-\-no\-dynamic\-linker\fR
|
||||||
|
Set the dynamic linker path to \fIfile\fR\. If no \fB\-I\fR option is given, or if \fB\-\-no\-dynamic\-linker\fR is given, no dynamic linker path is set to an output file\. This is contrary to the GNU linkers which set a default dynamic linker path in that case\. This difference doesn't usually make any difference because the compiler driver always passes \fB\-I\fR to the linker\.
|
||||||
|
.TP
|
||||||
|
\fB\-L\fR \fIdir\fR, \fB\-\-library\-path\fR=\fIdir\fR
|
||||||
|
Add \fIdir\fR to the list of library search paths from which \fBmold\fR searches libraries for the \fB\-l\fR option\.
|
||||||
|
.IP
|
||||||
|
Unlike the GNU linkers, \fBmold\fR does not have default search paths\. This difference doesn't usually make any difference because the compiler driver always passes all necessary search paths to the linker\.
|
||||||
|
.TP
|
||||||
|
\fB\-M\fR, \fB\-\-print\-map\fR
|
||||||
|
Write a map file to stdout\.
|
||||||
|
.TP
|
||||||
|
\fB\-N\fR, \fB\-\-omagic\fR, \fB\-\-no\-omagic\fR
|
||||||
|
Force \fBmold\fR to emit an output file with an old\-fashioned memory layout\. First, it makes the first data segment not aligned to a page boundary\. Second, text segments are marked as writable if the option is given\.
|
||||||
|
.TP
|
||||||
|
\fB\-S\fR, \fB\-\-strip\-debug\fR
|
||||||
|
Omit \fB\.debug_*\fR sections from the output file\.
|
||||||
|
.TP
|
||||||
|
\fB\-T\fR \fIfile\fR, \fB\-\-script\fR=\fIfile\fR
|
||||||
|
Read linker script from \fIfile\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-X\fR, \fB\-\-discard\-locals\fR
|
||||||
|
Discard temporary local symbols to reduce the sizes of the symbol table and the string table\. Temporary local symbols are local symbols starting with \fB\.L\fR\. Compilers usually generate such symbols for unnamed program elements such as string literals or floating\-point literals\. This is the default; use \fB\-\-discard\-none\fR to keep temporary local symbols\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-discard\-none\fR
|
||||||
|
Keep all local symbols in the symbol table, including temporary ones starting with \fB\.L\fR, except ones in mergeable sections\. This restores the default behavior of GNU ld\. \fBmold\fR and \fBld\.lld\fR discard temporary local symbols by default\.
|
||||||
|
.TP
|
||||||
|
\fB\-e\fR \fIsymbol\fR, \fB\-\-entry\fR=\fIsymbol\fR:
|
||||||
|
|
||||||
|
.TP
|
||||||
|
\fB\-f\fR \fIshlib\fR, \fB\-\-auxiliary\fR=\fIshlib\fR
|
||||||
|
Set the \fBDT_AUXILIARY\fR dynamic section field to \fIshlib\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-h\fR \fIlibname\fR, \fB\-\-soname\fR=\fIlibname\fR
|
||||||
|
Set the \fBDT_SONAME\fR dynamic section field to \fIlibname\fR\. This option is used when creating a shared object file\. Typically, when you create \fBlibfoo\.so\fR, you want to pass \fB\-\-soname=foo\fR to a linker\.
|
||||||
|
.TP
|
||||||
|
\fB\-l\fR \fIlibname\fR
|
||||||
|
Search for \fBlib\fR\fIlibname\fR\fB\.so\fR or \fBlib\fR\fIlibname\fR\fB\.a\fR from library search paths\.
|
||||||
|
.TP
|
||||||
|
\fB\-m\fR \fItarget\fR
|
||||||
|
Choose a \fItarget\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-o\fR \fIfile\fR, \fB\-\-output\fR=\fIfile\fR
|
||||||
|
Use \fIfile\fR as the output file name instead of the default name \fBa\.out\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-r\fR, \fB\-\-relocatable\fR
|
||||||
|
Instead of generating an executable or a shared object file, combine input object files to generate another object file that can be used as an input to a linker\.
|
||||||
|
.TP
|
||||||
|
\fB\-s\fR, \fB\-\-strip\-all\fR
|
||||||
|
Omit \fB\.symtab\fR section from the output file\.
|
||||||
|
.TP
|
||||||
|
\fB\-u\fR \fIsymbol\fR, \fB\-\-undefined\fR=\fIsymbol\fR
|
||||||
|
If \fIsymbol\fR remains as an undefined symbol after reading all object files, and if there is a static archive that contains an object file defining \fIsymbol\fR, pull out the object file and link it so that the output file contains a definition of \fIsymbol\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-y\fR \fIsymbol\fR, \fB\-\-trace\-symbol\fR=\fIsymbol\fR
|
||||||
|
Trace references to \fIsymbol\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Bdynamic\fR
|
||||||
|
Link against shared libraries\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Bstatic\fR
|
||||||
|
Do not link against shared libraries\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Bsymbolic\fR
|
||||||
|
When creating a shared library, make global symbols export\-only (i\.e\. do not import the same symbol)\. As a result, references within a shared library are always resolved locally, negating symbol override at runtime\. See "Dynamic symbol resolution" for more information about symbol imports and exports\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Bsymbolic\-functions\fR
|
||||||
|
This option has the same effect as \fB\-\-Bsymbolic\fR but works only for function symbols\. Data symbols remain being both imported and exported\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Bsymbolic\-non\-weak\fR
|
||||||
|
This option has the same effect as \fB\-\-Bsymbolic\fR but works only for non\-weak symbols\. Weak symbols remain being both imported and exported\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Bsymbolic\-non\-weak\-functions\fR
|
||||||
|
This option has the same effect as \fB\-\-Bsymbolic\fR but works only for non\-weak function symbols\. Data symbols and weak function symbols remain being both imported and exported\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Bno\-symbolic\fR
|
||||||
|
Cancel \fB\-\-Bsymbolic\fR, \fB\-\-Bsymbolic\-functions\fR, \fB\-\-Bsymbolic\-non\-weak\fR and \fB\-\-Bsymbolic\-non\-weak\-functions\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Map\fR=\fIfile\fR
|
||||||
|
Write map file to \fIfile\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Tbss\fR=\fIaddress\fR
|
||||||
|
Alias for \fB\-\-section\-start=\.bss=\fR\fIaddress\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Tdata\fR=\fIaddress\fR
|
||||||
|
Alias for \fB\-\-section\-start=\.data=\fR\fIaddress\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Ttext\fR=\fIaddress\fR
|
||||||
|
Alias for \fB\-\-section\-start=\.text=\fR\fIaddress\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-Ttext\-segment\fR=\fIaddress\fR
|
||||||
|
Set the address of the first byte of the text segment\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-allow\-multiple\-definition\fR
|
||||||
|
Normally, the linker reports an error if there are more than one definition of a symbol\. This option changes the default behavior so that it doesn't report an error for duplicate definitions and instead use the first definition\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-allow\-shlib\-undefined\fR, \fB\-\-no\-allow\-shlib\-undefined\fR
|
||||||
|
Even if mold succeeds in linking a main executable without undefined symbol errors, you may still encounter symbol lookup errors at runtime because the dynamic linker cannot find some symbols in shared libraries in any ELF module\. This occurs because mold ignores undefined symbols in shared libraries by default\.
|
||||||
|
.IP
|
||||||
|
If you pass \fB\-\-no\-allow\-shlib\-undefined\fR, mold verifies that undefined symbols in shared libraries given to the linker can be resolved at link\-time\. In other words, this converts the runtime error to a link\-time error\.
|
||||||
|
.IP
|
||||||
|
Note that you need to pass all shared libraries, including indirectly dependent ones, to the linker as arguments for \fB\-l\fR\. If a shared library depends on a library that's not passed to the linker, the verification will be skipped for that file\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-as\-needed\fR, \fB\-\-no\-as\-needed\fR
|
||||||
|
By default, shared libraries given to the linker are unconditionally added to the list of required libraries in an output file\. However, shared libraries after \fB\-\-as\-needed\fR are added to the list only when at least one symbol is actually used by the output file\. In other words, shared libraries after \fB\-\-as\-needed\fR are not added to the list of needed libraries if they are not needed by a program\.
|
||||||
|
.IP
|
||||||
|
The \fB\-\-no\-as\-needed\fR option restores the default behavior for subsequent files\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-build\-id\fR=[ \fBmd5\fR | \fBsha1\fR | \fBsha256\fR | \fBfast\fR | \fBuuid\fR | \fB0x\fR\fIhexstring\fR | \fBnone\fR ]
|
||||||
|
Create a \fB\.note\.gnu\.build\-id\fR section containing a byte string to uniquely identify an output file\. \fBsha256\fR compute a 256\-bit cryptographic hash of an output file and set it to build\-id\. \fBmd5\fR and \fBsha1\fR compute the same hash but truncate it to 128 and 160 bits, respectively, before setting it to build\-id\. \fBuuid\fR sets a random 128\-bit UUID\. \fB0x\fR\fIhexstring\fR sets \fIhexstring\fR\. \fBfast\fR is a synonym for \fBsha256\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-build\-id\fR
|
||||||
|
Synonym for \fB\-\-build\-id=sha256\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-no\-build\-id\fR
|
||||||
|
Synonym for \fB\-\-build\-id=none\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-compress\-debug\-sections\fR=[ \fBzlib\fR | \fBzlib\-gabi\fR | \fBzlib:\fR\fIN\fR | \fBzstd\fR | \fBzstd:\fR\fIN\fR | \fBnone\fR ]
|
||||||
|
Compress DWARF debug info (\fB\.debug_*\fR sections) using the zlib or zstd compression algorithm\. \fBzlib\-gabi\fR is an alias for \fBzlib\fR\. \fBzlib:\fR\fIN\fR selects the zlib compression level, where \fIN\fR is between 0 and 9 (0 means no compression), and \fBzstd:\fR\fIN\fR selects the zstd compression level, where \fIN\fR is between 1 and 22\. Higher levels achieve better compression ratios but are slower\. \fBzlib\fR is equivalent to \fBzlib:1\fR and \fBzstd\fR is equivalent to \fBzstd:3\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-defsym\fR=\fIsymbol\fR=\fIvalue\fR
|
||||||
|
Define \fIsymbol\fR as an alias for \fIvalue\fR\.
|
||||||
|
.IP
|
||||||
|
\fIvalue\fR is either an integer (in decimal or hexadecimal with \fB0x\fR prefix) or a symbol name\. If an integer is given as a value, \fIsymbol\fR is defined as an absolute symbol with the given value\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-default\-symver\fR
|
||||||
|
Use soname as a symbol version and append that version to all symbols\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-demangle\fR, \fB\-\-no\-demangle\fR
|
||||||
|
Demangle C++ and Rust symbols in log messages\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-dependency\-file\fR=\fIfile\fR
|
||||||
|
Write a dependency file to \fIfile\fR\. The contents of the written file is readable by make(1), which defines only one rule with the linker's output file as a target and all input files as its prerequisites\. Users are expected to include the generated dependency file into a Makefile to automate the dependency management\. This option is analogous to the compiler's \fB\-MM \-MF\fR options\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-dynamic\-list\fR=\fIfile\fR
|
||||||
|
Read a list of dynamic symbols from \fIfile\fR\. Same as \fB\-\-export\-dynamic\-symbol\-list\fR, except that it implies \fB\-\-Bsymbolic\fR\. If \fIfile\fR does not exist in the current directory, it is searched from library search paths for the sake of compatibility with GNU ld\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-eh\-frame\-hdr\fR, \fB\-\-no\-eh\-frame\-hdr\fR
|
||||||
|
Create \fB\.eh_frame_hdr\fR section\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-emit\-relocs\fR
|
||||||
|
The linker usually "consumes" relocation sections\. That is, the linker applies relocations to other sections, and relocation sections themselves are discarded\.
|
||||||
|
.IP
|
||||||
|
The \fB\-\-emit\-relocs\fR instructs the linker to leave relocation sections in the output file\. Some post\-link binary analysis or optimization tools such as LLVM Bolt need them\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-enable\-new\-dtags\fR, \fB\-\-disable\-new\-dtags\fR
|
||||||
|
By default, \fBmold\fR emits \fBDT_RUNPATH\fR for \fB\-\-rpath\fR\. If you pass \fB\-\-disable\-new\-dtags\fR, \fBmold\fR emits \fBDT_RPATH\fR for \fB\-\-rpath\fR instead\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-execute\-only\fR:
|
||||||
|
|
||||||
|
.TP
|
||||||
|
\fB\-\-exclude\-libs\fR=\fIlibraries\fR \|\.\|\.\|\.
|
||||||
|
Mark all symbols in the given \fIlibraries\fR hidden\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-export\-dynamic\-symbol\fR=\fIsymbol\fR
|
||||||
|
Put symbols matching \fIsymbol\fR in the dynamic symbol table\. \fIsymbol\fR may be a glob pattern in the same syntax as for the \fB\-\-export\-dynamic\-symbol\-list\fR or \fB\-\-version\-script\fR options\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-export\-dynamic\-symbol\-list\fR=\fIfile\fR
|
||||||
|
Read a list of dynamic symbols from \fIfile\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-fatal\-warnings\fR, \fB\-\-no\-fatal\-warnings\fR
|
||||||
|
Treat warnings as errors\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-fini\fR=\fIsymbol\fR
|
||||||
|
Call \fIsymbol\fR at unload\-time\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-gc\-sections\fR, \fB\-\-no\-gc\-sections\fR
|
||||||
|
Remove unreferenced sections\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-gdb\-index\fR
|
||||||
|
Create a \fB\.gdb_index\fR section to speed up GNU debugger\. To use this, you need to compile source files with the \fB\-ggnu\-pubnames\fR compiler flag\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-hash\-style\fR=[ \fBsysv\fR | \fBgnu\fR | \fBboth\fR | \fBnone\fR ]
|
||||||
|
Set hash style\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-icf\fR=[ \fBsafe\fR | \fBall\fR | \fBnone\fR ], \fB\-\-no\-icf\fR
|
||||||
|
It is not uncommon for a program to contain many identical functions that differ only in name\. For example, a C++ template \fBstd::vector\fR is very likely to be instantiated to the identical code for \fBstd::vector<int>\fR and \fBstd::vector<unsigned>\fR because the container cares only about the size of the parameter type\. Identical Code Folding (ICF) is a size optimization to identify and merge such identical functions\.
|
||||||
|
.IP
|
||||||
|
If \fB\-\-icf=all\fR is given, \fBmold\fR tries to merge all identical functions\. This reduces the size of the output most, but it is not a "safe" optimization\. It is guaranteed in C and C++ that two pointers pointing two different functions will never be equal, but \fB\-\-icf=all\fR breaks that assumption as two identical functions have the same address after merging\. So a care must be taken when you use this flag that your program does not depend on the function pointer uniqueness\.
|
||||||
|
.IP
|
||||||
|
\fB\-\-icf=safe\fR is a flag to merge functions only when it is safe to do so\. That is, if a program does not take an address of a function, it is safe to merge that function with other function, as you cannot compare a function pointer with something else without taking an address of a function\.
|
||||||
|
.IP
|
||||||
|
\fB\-\-icf=safe\fR needs to be used with a compiler that supports \fB\.llvm_addrsig\fR section which contains the information as to what symbols are address\-taken\. LLVM/Clang supports that section by default\. Since GCC does not support it yet, you cannot use \fB\-\-icf=safe\fR with GCC (it doesn't do any harm but can't optimize at all\.)
|
||||||
|
.IP
|
||||||
|
\fB\-\-icf=none\fR and \fB\-\-no\-icf\fR disables ICF\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-ignore\-data\-address\-equality\fR
|
||||||
|
Make ICF to merge not only functions but also data\. This option should be used in combination with \fB\-\-icf=all\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-image\-base\fR=\fIaddr\fR
|
||||||
|
Set the base address to \fIaddr\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-init\fR=\fIsymbol\fR
|
||||||
|
Call \fIsymbol\fR at load\-time\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-no\-undefined\fR
|
||||||
|
Report undefined symbols (even with \fB\-\-shared\fR)\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-noinhibit\-exec\fR
|
||||||
|
Create an output file even if errors occur\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-package\-metadata\fR=\fIpercent\-encoded\-string\fR
|
||||||
|
Embed a specified string into the \fB\.note\.package\fR section\. This option is designed for build scripts that generate binary packages, such as \fB\.rpm\fR or \fB\.deb\fR, to include package metadata in each executable\. It simplifies the process of identifying the corresponding package for a given executable or core file\.
|
||||||
|
.IP
|
||||||
|
An argument to this option is treated as percent\-encoded and decoded before being inserted into the section, allowing you to avoid the use of the comma (\fB,\fR) character in the argument\. This is useful because the compiler replaces all occurrences of commas in \fB\-Wl,\fR with spaces before forwarding them to the linker\. Note that \fBmold\fR always interprets the argument as percent\-encoded, so you also need to escape all occurrences of \fB%\fR as \fB%25\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-pack\-dyn\-relocs\fR=[ \fBrelr\fR | \fBandroid\fR | \fBandroid+relr\fR | \fBnone\fR ]
|
||||||
|
Compress dynamic relocations in the output file\.
|
||||||
|
.IP
|
||||||
|
If \fBrelr\fR is specified, all \fBR_*_RELATIVE\fR relocations are put into \fB\.relr\.dyn\fR section instead of \fB\.rel\.dyn\fR or \fB\.rela\.dyn\fR section\. Since \fB\.relr\.dyn\fR section uses a space\-efficient encoding scheme, specifying this flag can reduce the size of the output\. This is typically most effective for position\-independent executable\.
|
||||||
|
.IP
|
||||||
|
If \fBandroid\fR is specified, all dynamic relocations are encoded in Android's packed relocation format (APS2) and stored in the \fB\.rel\.dyn\fR or \fB\.rela\.dyn\fR section, whose section type is changed to \fBSHT_ANDROID_REL\fR or \fBSHT_ANDROID_RELA\fR\. The dynamic table is updated to use \fBDT_ANDROID_REL\fR / \fBDT_ANDROID_RELA\fR and their \fBSZ\fR variants in place of the standard tags\.
|
||||||
|
.IP
|
||||||
|
\fBandroid+relr\fR combines both: \fBR_*_RELATIVE\fR relocations go to \fB\.relr\.dyn\fR and the rest are APS2\-encoded\. This is the configuration used by most Android system binaries\.
|
||||||
|
.IP
|
||||||
|
Note that a runtime loader has to support \fB\.relr\.dyn\fR to run executables or shared libraries linked with \fB\-\-pack\-dyn\-relocs=relr\fR\. As of 2026, glibc (since 2\.36), musl (since 1\.2\.4), Android, ChromeOS, and Fuchsia all support it\. The APS2 format, on the other hand, is only handled by Android's bionic loader; the encoder itself is target\-agnostic, but the produced binary can only be loaded on platforms where bionic (or a compatible loader) handles \fBDT_ANDROID_REL(A)\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-pie\fR, \fB\-\-pic\-executable\fR, \fB\-\-no\-pie\fR, \fB\-\-no\-pic\-executable\fR
|
||||||
|
Create a position\-independent executable\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-print\-gc\-sections\fR, \fB\-\-no\-print\-gc\-sections\fR
|
||||||
|
Print removed unreferenced sections\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-print\-icf\-sections\fR, \fB\-\-no\-print\-icf\-sections\fR
|
||||||
|
Print folded identical sections\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-push\-state\fR, \fB\-\-pop\-state\fR
|
||||||
|
\fB\-\-push\-state\fR saves the current values of \fB\-\-as\-needed\fR, \fB\-\-whole\-archive\fR, \fB\-\-static\fR, and \fB\-\-start\-lib\fR\. The saved values can be restored by pop\-state\.
|
||||||
|
.IP
|
||||||
|
\fB\-\-push\-state\fR and \fB\-\-pop\-state\fR pairs can nest\.
|
||||||
|
.IP
|
||||||
|
These options are useful when you want to construct linker command line options programmatically\. For example, if you want to link \fBlibfoo\.so\fR by as\-needed basis but don't want to change the global state of \fB\-\-as\-needed\fR, you can append \fB\-\-push\-state \-\-as\-needed \-lfoo \-\-pop\-state\fR to the linker command line options\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-relax, \-\-no\-relax\fR
|
||||||
|
Rewrite machine instructions with more efficient ones for some relocations\. The feature is enabled by default\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-require\-defined\fR=\fIsymbol\fR
|
||||||
|
Like \fB\-\-undefined\fR, except the new symbol must be defined by the end of the link\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-retain\-symbols\-file\fR=\fIfile\fR
|
||||||
|
Keep only symbols listed in \fIfile\fR\. \fIfile\fR is a text file containing a symbol name on each line\. \fBmold\fR discards all local symbols as well as global symbol that are not in \fIfile\fR\. Note that this option removes symbols only from \fB\.symtab\fR section and does not affect \fB\.dynsym\fR section, which is used for dynamic linking\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-rpath\fR=\fIdir\fR
|
||||||
|
Add \fIdir\fR to runtime search paths\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-section\-start\fR=\fIsection\fR=\fIaddress\fR
|
||||||
|
Set \fIaddress\fR to section\. \fIaddress\fR is a hexadecimal number that may start with an optional \fB0x\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-shared\fR, \fB\-\-Bshareable\fR
|
||||||
|
Create a share library\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-spare\-dynamic\-tags\fR=\fInumber\fR
|
||||||
|
Append the given number of \fBDT_NULL\fR entries to the end of the \fB\.dynamic\fR section, so that post\-link processing tools can easily add new dynamic tags by overwriting the null entries\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-start\-lib\fR, \fB\-\-end\-lib\fR
|
||||||
|
Handle object files between \fB\-\-start\-lib\fR and \fB\-\-end\-lib\fR as if they were in an archive file\. That means object files between them are linked only when they are needed to resolve undefined symbols\. The options are useful if you want to link object files only when they are needed but want to avoid the overhead of running ar(3)\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-static\fR
|
||||||
|
Do not link against shared libraries\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-sysroot\fR=\fIdir\fR
|
||||||
|
Set target system root directory to \fIdir\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-trace\fR
|
||||||
|
Print name of each input file\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-undefined\-glob\fR=\fIpattern\fR
|
||||||
|
Synonym for \fB\-\-undefined\fR, except that \fB\-\-undefined\-glob\fR takes a glob pattern instead of just a single symbol name\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-undefined\-version\fR, \fB\-\-no\-undefined\-version\fR
|
||||||
|
By default, \fBmold\fR warns on a symbol specified by a version script or by \fB\-\-export\-dynamic\-symbol\fR if it is not defined\. You can silence the warning by \fB\-\-undefined\-version\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-unique\fR=\fIpattern\fR
|
||||||
|
Don't merge input sections that match the given glob pattern \fIpattern\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-unresolved\-symbols\fR=[ \fBreport\-all\fR | \fBignore\-all\fR | \fBignore\-in\-object\-files\fR | \fBignore\-in\-shared\-libs\fR ]
|
||||||
|
How to handle undefined symbols\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-version\-script\fR=\fIfile\fR
|
||||||
|
Read version script from \fIfile\fR\. If \fIfile\fR does not exist in the current directory, it is searched from library search paths for the sake of compatibility with GNU ld\.
|
||||||
|
.TP
|
||||||
|
\fB\-w\fR, \fB\-\-no\-warnings\fR
|
||||||
|
Suppress warnings and cancel \fB\-\-fatal\-warnings\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-warn\-common\fR, \fB\-\-no\-warn\-common\fR
|
||||||
|
Warn about common symbols\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-warn\-once\fR
|
||||||
|
Only warn once for each undefined symbol instead of warn for each relocation referring an undefined symbol\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-warn\-unresolved\-symbols\fR, \fB\-\-error\-unresolved\-symbols\fR
|
||||||
|
Normally, the linker reports an error for unresolved symbols\. \fB\-\-warn\-unresolved\-symbols\fR option turns it into a warning\. \fB\-\-error\-unresolved\-symbols\fR option restores the default behavior\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-whole\-archive\fR, \fB\-\-no\-whole\-archive\fR
|
||||||
|
When archive files (\fB\.a\fR files) are given to the linker, only object files that are needed to resolve undefined symbols are extracted from them and linked to an output file\. \fB\-\-whole\-archive\fR changes that behavior for subsequent archives so that the linker extracts all object files and links them to an output\. For example, if you are creating a shared object file and you want to include all archive members to the output, you should pass \fB\-\-whole\-archive\fR\. \fB\-\-no\-whole\-archive\fR restores the default behavior for subsequent archives\.
|
||||||
|
.TP
|
||||||
|
\fB\-\-wrap\fR=\fIsymbol\fR
|
||||||
|
Make \fIsymbol\fR be resolved to \fB__wrap_\fR\fIsymbol\fR\. The original symbol can be resolved as \fB__real_\fR\fIsymbol\fR\. This option is typically used for wrapping an existing function\.
|
||||||
|
.TP
|
||||||
|
\fB\-z cet\-report\fR=[ \fBwarning\fR | \fBerror\fR | \fBnone\fR ]
|
||||||
|
Intel Control\-flow Enforcement Technology (CET) is a new x86 feature available since Tiger Lake which is released in 2020\. It defines new instructions to harden security to protect programs from control hijacking attacks\. You can tell the compiler to use the feature by specifying the \fB\-fcf\-protection\fR flag\.
|
||||||
|
.IP
|
||||||
|
\fB\-z cet\-report\fR flag is used to make sure that all object files were compiled with a correct \fB\-fcf\-protection\fR flag\. If \fBwarning\fR or \fBerror\fR are given, \fBmold\fR prints out a warning or an error message if an object file was not compiled with the compiler flag\.
|
||||||
|
.IP
|
||||||
|
\fBmold\fR looks for \fBGNU_PROPERTY_X86_FEATURE_1_IBT\fR bit and \fBGNU_PROPERTY_X86_FEATURE_1_SHSTK\fR bit in \fB\.note\.gnu\.property\fR section to determine whether or not an object file was compiled with \fB\-fcf\-protection\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-z now\fR, \fB\-z lazy\fR
|
||||||
|
By default, functions referring to other ELF modules are resolved by the dynamic linker when they are called for the first time\. \fB\-z now\fR marks an executable or a shared library file so that all dynamic symbols are resolved when a file is loaded to memory\. \fB\-z lazy\fR restores the default behavior\.
|
||||||
|
.TP
|
||||||
|
\fB\-z origin\fR
|
||||||
|
Mark object requiring immediate \fB$ORIGIN\fR processing at runtime\.
|
||||||
|
.TP
|
||||||
|
\fB\-z ibt\fR
|
||||||
|
Turn on \fBGNU_PROPERTY_X86_FEATURE_1_IBT\fR bit in \fB\.note\.gnu\.property\fR section to indicate that the output uses IBT\-enabled PLT\. This option implies \fB\-z ibtplt\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-z ibtplt\fR
|
||||||
|
Generate Intel Branch Tracking (IBT)\-enabled PLT which is the default on x86\-64\. This is the default\.
|
||||||
|
.TP
|
||||||
|
\fB\-z execstack\fR, \fB\-z noexecstack\fR
|
||||||
|
By default, the pages for the stack area (i\.e\. the pages where local variables reside) are not executable for security reasons\. \fB\-z execstack\fR makes it executable\. \fB\-z noexecstack\fR restores the default behavior\.
|
||||||
|
.TP
|
||||||
|
\fB\-z keep\-text\-section\-prefix\fR, \fB\-z nokeep\-text\-section\-prefix\fR
|
||||||
|
Keep \fB\.text\.hot\fR, \fB\.text\.unknown\fR, \fB\.text\.unlikely\fR, \fB\.text\.startup\fR, and \fB\.text\.exit\fR as separate sections in the final binary instead of merging them as \fB\.text\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-z rodynamic\fR
|
||||||
|
Make the \fB\.dynamic\fR section read\-only\.
|
||||||
|
.TP
|
||||||
|
\fB\-z relro\fR, \fB\-z norelro\fR
|
||||||
|
Some sections such as \fB\.dynamic\fR have to be writable only during a module is being loaded to memory\. Once the dynamic linker finishes its job, such sections won't be mutated by anyone\. As a security mitigation, it is preferred to make such segments read\-only during program execution\.
|
||||||
|
.IP
|
||||||
|
\fB\-z relro\fR puts such sections into a special segment called \fBrelro\fR\. The dynamic linker makes a relro segment read\-only after it finishes its job\.
|
||||||
|
.IP
|
||||||
|
By default, \fBmold\fR generates a relro segment\. \fB\-z norelro\fR disables the feature\.
|
||||||
|
.TP
|
||||||
|
\fB\-z sectionheader\fR, \fB\-z nosectionheader\fR
|
||||||
|
\fB\-z nosectionheader\fR tell the linker to omit the section header\. By default, the linker does not omit the section header\.
|
||||||
|
.TP
|
||||||
|
\fB\-z separate\-loadable\-segments\fR, \fB\-z separate\-code\fR, \fB\-z noseparate\-code\fR
|
||||||
|
If one memory page contains multiple segments, the page protection bits are set in such a way that the needed attributes (writable or executable) are satisfied for all segments\. This usually happens at a boundary of two segments with two different attributes\.
|
||||||
|
.IP
|
||||||
|
\fBseparate\-loadable\-segments\fR adds paddings between segments with different attributes so that they do not share the same page\.
|
||||||
|
.IP
|
||||||
|
\fBseparate\-code\fR adds paddings only between executable and non\-executable segments\. This is the default\.
|
||||||
|
.IP
|
||||||
|
\fBnoseparate\-code\fR does not add any paddings between segments\.
|
||||||
|
.TP
|
||||||
|
\fB\-z defs\fR, \fB\-z nodefs\fR
|
||||||
|
Report undefined symbols (even with \fB\-\-shared\fR)\.
|
||||||
|
.TP
|
||||||
|
\fB\-z shstk\fR
|
||||||
|
Enforce shadow stack by turning \fBGNU_PROPERTY_X86_FEATURE_1_SHSTK\fR bit in \fB\.note\.gnu\.property\fR output section\. Shadow stack is part of Intel Control\-flow Enforcement Technology (CET), which is available since Tiger Lake (2020)\.
|
||||||
|
.TP
|
||||||
|
\fB\-z start_stop_visibility\fR=[ \fBhidden\fR | \fBprotected\fR ]
|
||||||
|
If a section name is valid as a C identifier (i\.e\., it matches \fB/^[_a\-zA\-Z][_a\-zA\-Z0\-9]*$/\fR), mold creates \fB__start_SECNAME\fR and \fB__stop_SECNAME\fR symbols to mark the beginning and end of the section, where \fBSECNAME\fR is the section name\.
|
||||||
|
.IP
|
||||||
|
You can make these marker symbols visible from other ELF modules by passing \fB\-z start_stop_visibility=protected\fR\. Default is \fBhidden\fR\.
|
||||||
|
.TP
|
||||||
|
\fB\-z text\fR, \fB\-z notext\fR, \fB\-z textoff\fR
|
||||||
|
\fBmold\fR by default reports an error if dynamic relocations are created in read\-only sections\. If \fB\-z notext\fR or \fB\-z textoff\fR are given, \fBmold\fR creates such dynamic relocations without reporting an error\. \fB\-z text\fR restores the default behavior\.
|
||||||
|
.TP
|
||||||
|
\fB\-z max\-page\-size\fR=\fInumber\fR
|
||||||
|
Some CPU ISAs support multiple memory page sizes\. This option specifies the maximum page size that an output binary can run on\. In general, binaries built for a larger page size can run on a system with a smaller page size, but not vice versa\. The default value is 4 KiB for i386, x86\-64, and RISC\-V, and 64 KiB for ARM64\.
|
||||||
|
.TP
|
||||||
|
\fB\-z nodefaultlib\fR
|
||||||
|
Make the dynamic loader ignore default search paths\.
|
||||||
|
.TP
|
||||||
|
\fB\-z nodelete\fR
|
||||||
|
Mark DSO non\-deletable at runtime\.
|
||||||
|
.TP
|
||||||
|
\fB\-z nodlopen\fR
|
||||||
|
Mark DSO not available to dlopen(3)\. This option makes it possible for the linker to optimize thread\-local variable accesses by rewriting instructions for some targets\.
|
||||||
|
.TP
|
||||||
|
\fB\-z nodump\fR
|
||||||
|
Mark DSO not available to dldump(3)\.
|
||||||
|
.TP
|
||||||
|
\fB\-z nocopyreloc\fR
|
||||||
|
Do not create copy relocations\.
|
||||||
|
.TP
|
||||||
|
\fB\-z initfirst\fR
|
||||||
|
Mark DSO to be initialized first at runtime\.
|
||||||
|
.TP
|
||||||
|
\fB\-z interpose\fR
|
||||||
|
Mark object to interpose all DSOs but executable\.
|
||||||
|
.TP
|
||||||
|
\fB\-(\fR, \fB\-)\fR, \fB\-EL\fR, \fB\-O\fR\fInumber\fR, \fB\-\-dc\fR, \fB\-\-dp\fR, \fB\-\-end\-group\fR, \fB\-\-no\-add\-needed\fR, \fB\-\-no\-copy\-dt\-needed\-entries\fR, \fB\-\-nostdlib\fR, \fB\-\-rpath\-link=Ar dir\fR, \fB\-\-sort\-common\fR, \fB\-\-sort\-section\fR, \fB\-\-start\-group\fR, \fB\-\-warn\-constructors\fR, \fB\-\-warn\-once\fR, \fB\-\-fix\-cortex\-a53\-835769\fR, \fB\-\-fix\-cortex\-a53\-843419\fR, \fB\-z combreloc\fR, \fB\-z common\-page\-size\fR, \fB\-z nocombreloc\fR
|
||||||
|
Ignored
|
||||||
|
.SH "ENVIRONMENT VARIABLES"
|
||||||
|
.TP
|
||||||
|
\fBMOLD_JOBS\fR
|
||||||
|
If this variable is set to \fB1\fR, only one \fBmold\fR process will run at a time\. If a new mold process is initiated while another is already active, the new process will wait until the active one completes before starting\.
|
||||||
|
.IP
|
||||||
|
The primary reason for this environment variable is to minimize peak memory usage\. Since mold is designed to operate with high parallelism, running multiple mold instances simultaneously may not be beneficial\. If you execute N instances of mold concurrently, it could require N times the time and N times the memory\. On the other hand, running them one after the other might still take N times longer, but the peak memory usage would be the same as running just a single instance\.
|
||||||
|
.IP
|
||||||
|
If your build system invokes multiple linker processes simultaneously and some of them often get killed due to out\-of\-memory errors, you might consider setting this environment variable to \fB1\fR to see if it addresses the OOM issue\.
|
||||||
|
.IP
|
||||||
|
Currently, any value other than \fB1\fR is silently ignored\.
|
||||||
|
.TP
|
||||||
|
\fBMOLD_DEBUG\fR
|
||||||
|
If this variable is set to a non\-empty string, \fBmold\fR embeds its command\-line options in the output file's \fB\.comment\fR section\.
|
||||||
|
.TP
|
||||||
|
\fBMOLD_REPRO\fR
|
||||||
|
Setting this variable to a non\-empty string has the same effect as passing the \fB\-\-repro\fR option\.
|
||||||
|
.SH "SEE ALSO"
|
||||||
|
gold(1), ld(1), elf(5), ld\.so(8)
|
||||||
|
.SH "AUTHOR"
|
||||||
|
Rui Ueyama \fIruiu@cs\.stanford\.edu\fR
|
||||||
|
.SH "BUGS"
|
||||||
|
Report bugs to \fIhttps://github\.com/rui314/mold/issues\fR\.
|
||||||
+995
@@ -0,0 +1,995 @@
|
|||||||
|
mold(1) -- a modern linker
|
||||||
|
==========================
|
||||||
|
|
||||||
|
## SYNOPSIS
|
||||||
|
|
||||||
|
`mold` [_option_...] _file_...
|
||||||
|
|
||||||
|
## DESCRIPTION
|
||||||
|
`mold` is a faster drop-in replacement for the default GNU ld(1).
|
||||||
|
|
||||||
|
### How to use
|
||||||
|
See <https://github.com/rui314/mold#how-to-use>.
|
||||||
|
|
||||||
|
### Compatibility
|
||||||
|
|
||||||
|
`mold` is designed to be a drop-in replacement for the GNU linkers for
|
||||||
|
linking user-land programs. If your user-land program cannot be built due to
|
||||||
|
missing command-line options, please file a bug at
|
||||||
|
<https://github.com/rui314/mold/issues>.
|
||||||
|
|
||||||
|
`mold` supports a very limited set of linker script features, which is just
|
||||||
|
sufficient to read `/usr/lib/x86_64-linux-gnu/libc.so` on Linux systems (on
|
||||||
|
Linux, that file is contrary to its name not a shared library but an ASCII
|
||||||
|
linker script that loads a real `libc.so` file.)
|
||||||
|
|
||||||
|
Beyond that, we have no plan to support any additional linker script features.
|
||||||
|
The linker script is an ad-hoc, over-designed, complex language which we
|
||||||
|
believe needs to be replaced by a simpler mechanism. We have a plan to add a
|
||||||
|
replacement for the linker script to `mold` instead.
|
||||||
|
|
||||||
|
### Archive symbol resolution
|
||||||
|
|
||||||
|
Traditionally, Unix linkers are sensitive to the order in which input files
|
||||||
|
appear on the command line. They process input files from the first (leftmost)
|
||||||
|
file to the last (rightmost) file one-by-one. While reading input files, they
|
||||||
|
maintain sets of defined and undefined symbols. When visiting an archive file
|
||||||
|
(`.a` files), they pull out object files to resolve as many undefined symbols
|
||||||
|
as possible and move on to the next input file. Object files that weren't
|
||||||
|
pulled out will never have a chance for a second look.
|
||||||
|
|
||||||
|
Due to this behavior, you usually have to add archive files at the end of a
|
||||||
|
command line, so that when a linker reaches archive files, it knows what
|
||||||
|
symbols remain as undefined.
|
||||||
|
|
||||||
|
If you put archive files at the beginning of a command line, a linker doesn't
|
||||||
|
have any undefined symbols, and thus no object files will be pulled out from
|
||||||
|
archives. You can change the processing order by using the `--start-group` and
|
||||||
|
`--end-group` options, though they make a linker slower.
|
||||||
|
|
||||||
|
`mold`, as well as the LLVM lld(1) linker, takes a different approach. They
|
||||||
|
remember which symbols can be resolved from archive files instead of
|
||||||
|
forgetting them after processing each archive. Therefore, `mold` and lld(1)
|
||||||
|
can "go back" in a command line to pull out object files from archives if they
|
||||||
|
are needed to resolve remaining undefined symbols. They are not sensitive to
|
||||||
|
the input file order.
|
||||||
|
|
||||||
|
`--start-group` and `--end-group` are still accepted by `mold` and lld(1)
|
||||||
|
for compatibility with traditional linkers, but they are silently ignored.
|
||||||
|
|
||||||
|
### Dynamic symbol resolution
|
||||||
|
|
||||||
|
Some Unix linker features are difficult to understand without comprehending
|
||||||
|
the semantics of dynamic symbol resolution. Therefore, even though it's not
|
||||||
|
specific to `mold`, we'll explain it here.
|
||||||
|
|
||||||
|
We use "ELF module" or just "module" as a collective term to refer to an
|
||||||
|
executable or a shared library file in the ELF format.
|
||||||
|
|
||||||
|
An ELF module may have lists of imported symbols and exported symbols, as well
|
||||||
|
as a list of shared library names from which imported symbols should be
|
||||||
|
imported. The point is that imported symbols are not bound to any specific
|
||||||
|
shared library until runtime.
|
||||||
|
|
||||||
|
Here is how the Unix dynamic linker resolves dynamic symbols. Upon the start
|
||||||
|
of an ELF program, the dynamic linker constructs a list of ELF modules which,
|
||||||
|
as a whole, consist of a complete program. The executable file is always at
|
||||||
|
the beginning of the list followed by its dependent shared libraries. An
|
||||||
|
imported symbol is searched from the beginning of the list to the end. If two
|
||||||
|
or more modules define the same symbol, the one that appears first in the list
|
||||||
|
takes precedence over the others.
|
||||||
|
|
||||||
|
This Unix semantics are contrary to systems such as Windows that have a
|
||||||
|
two-level namespace for dynamic symbols. On Windows, for example, dynamic
|
||||||
|
symbols are represented as a tuple of (`symbol-name`, `shared-library-name`),
|
||||||
|
so that each dynamic symbol is guaranteed to be resolved from some specific
|
||||||
|
library.
|
||||||
|
|
||||||
|
Typically, an ELF module that exports a symbol also imports the same symbol.
|
||||||
|
Such a symbol is usually resolved to itself, but that's not the case if a
|
||||||
|
module that appears before it in the symbol search list provides another
|
||||||
|
definition of the same symbol.
|
||||||
|
|
||||||
|
Let's take `malloc` as an example. Assume that you define your version of
|
||||||
|
`malloc` in your main executable file. Then, all `malloc` calls from any
|
||||||
|
module are resolved to your function instead of the one in libc, because the
|
||||||
|
executable is always at the beginning of the dynamic symbol search list. Note
|
||||||
|
that even `malloc` calls within libc are resolved to your definition since
|
||||||
|
libc exports and imports `malloc`. Therefore, by defining `malloc` yourself,
|
||||||
|
you can overwrite a library function, and the `malloc` in libc becomes dead
|
||||||
|
code.
|
||||||
|
|
||||||
|
These Unix semantics are tricky and sometimes considered harmful. For example,
|
||||||
|
assume that you accidentally define `atoi` as a global function in your
|
||||||
|
executable that behaves completely differently from the one in the C standard.
|
||||||
|
Then, all `atoi` function calls from any modules (even function calls within
|
||||||
|
libc) are redirected to your function instead of the one in libc, which will
|
||||||
|
very likely cause a problem. That is a somewhat surprising consequence for an
|
||||||
|
accidental name conflict. On the other hand, this semantic is sometimes useful
|
||||||
|
because it allows users to override library functions without rebuilding
|
||||||
|
modules containing them.
|
||||||
|
|
||||||
|
Whether good or bad, you should keep these semantics in mind to understand
|
||||||
|
Unix linkers' behaviors.
|
||||||
|
|
||||||
|
### Build reproducibility
|
||||||
|
|
||||||
|
`mold`'s output is deterministic. That is, if you pass the same object files
|
||||||
|
and the same command-line options to the same version of `mold`, it is
|
||||||
|
guaranteed that `mold` produces the bit-for-bit identical output. The linker's
|
||||||
|
internal randomness, such as the timing of thread scheduling or iteration
|
||||||
|
orders of hash tables, doesn't affect the output.
|
||||||
|
|
||||||
|
`mold` does not have any host-specific default settings. This is contrary to the
|
||||||
|
GNU linkers, for which some configurable values, such as system-dependent
|
||||||
|
library search paths, are hard-coded. `mold` depends only on its command-line
|
||||||
|
arguments.
|
||||||
|
|
||||||
|
## OPTION NOTATIONS
|
||||||
|
|
||||||
|
Multi-letter long options may precede either a single dash or double dashes,
|
||||||
|
except for those starting with the letter "o". For historical reasons, long
|
||||||
|
options beginning with "o" must precede double dashes.
|
||||||
|
|
||||||
|
For example, you can spell `--as-needed` as `-as-needed`, but `--omagic` must
|
||||||
|
not be spelled as `-omagic`. `-omagic` will be interpreted not as `--omagic`
|
||||||
|
but as `-o magic`.
|
||||||
|
|
||||||
|
## MOLD-SPECIFIC OPTIONS
|
||||||
|
|
||||||
|
* `--chroot`=_dir_:
|
||||||
|
Set _dir_ as the root directory.
|
||||||
|
|
||||||
|
* `--color-diagnostics`=[ _auto_ | _always_ | _never_ ]:
|
||||||
|
Show diagnostic messages in color using ANSI escape sequences. `auto` means
|
||||||
|
that `mold` prints out messages in color only if the standard output is
|
||||||
|
connected to a TTY. Default is `auto`.
|
||||||
|
|
||||||
|
* `--color-diagnostics`:
|
||||||
|
Synonym for `--color-diagnostics=auto`.
|
||||||
|
|
||||||
|
* `--no-color-diagnostics`:
|
||||||
|
Synonym for `--color-diagnostics=never`.
|
||||||
|
|
||||||
|
* `--detach`, `--no-detach`:
|
||||||
|
Permit or do not permit mold to create a debug info file in the background.
|
||||||
|
|
||||||
|
* `--fork`, `--no-fork`:
|
||||||
|
Spawn a child process and let it do the actual linking. When linking a large
|
||||||
|
program, the OS kernel can take a few hundred milliseconds to terminate a
|
||||||
|
`mold` process. `--fork` hides that latency. By default, it does fork.
|
||||||
|
|
||||||
|
Note that `--fork` also hides the resource usage statistics reported by
|
||||||
|
time(2), since it doesn't call waitpid(2) on the child process. If you
|
||||||
|
need those statistics, pass `--no-fork`.
|
||||||
|
|
||||||
|
* `--perf`:
|
||||||
|
Print performance statistics.
|
||||||
|
|
||||||
|
* `--print-dependencies`:
|
||||||
|
Print out dependency information for input files.
|
||||||
|
|
||||||
|
Each line of the output for this option shows which file depends on which
|
||||||
|
file to use a specific symbol. This option is useful for debugging why some
|
||||||
|
object file in a static archive got linked or why some shared library is
|
||||||
|
kept in an output file's dependency list even with `--as-needed`.
|
||||||
|
|
||||||
|
* `--relocatable-merge-sections`:
|
||||||
|
By default, `mold` doesn't merge input sections by name when merging input
|
||||||
|
object files into a single output object file for `-r`. For example,
|
||||||
|
`.text.foo` and `.text.bar` aren't merged for `-r` even though they are
|
||||||
|
merged into `.text` based on the default section merging rules.
|
||||||
|
|
||||||
|
This option changes the behavior so that `mold` merges input sections by
|
||||||
|
name by the default section merging rules.
|
||||||
|
|
||||||
|
* `--repro`:
|
||||||
|
Archive input files, as well as a text file containing command line options,
|
||||||
|
in a tar file so that you can run `mold` with the exact same inputs again.
|
||||||
|
This is useful for reporting a bug with a reproducer. The output filename is
|
||||||
|
`path/to/output.tar`, where `path/to/output` is an output filename specified
|
||||||
|
by `-o`.
|
||||||
|
|
||||||
|
* `--reverse-sections`:
|
||||||
|
Reverse the order of input sections before assigning them the offsets in the
|
||||||
|
output file.
|
||||||
|
|
||||||
|
This option is useful for finding bugs that depend on the initialization
|
||||||
|
order of global objects. In C++, constructors of global objects in a single
|
||||||
|
source file are guaranteed to be executed in the source order, but there's
|
||||||
|
no such guarantee across compilation units. Usually, constructors are
|
||||||
|
executed in the order given to the linker, but depending on it is a mistake.
|
||||||
|
|
||||||
|
By reversing the order of input sections using `--reverse-sections`, you can
|
||||||
|
easily test that your program works in the reversed initialization order.
|
||||||
|
|
||||||
|
* `--run` _command_ _arg_...:
|
||||||
|
Run _command_ with `mold` as `/usr/bin/ld`. Specifically, `mold` runs a
|
||||||
|
given command with the `LD_PRELOAD` environment set to intercept exec(3)
|
||||||
|
family functions and replaces `argv[0]` with itself if it is `ld`,
|
||||||
|
`ld.gold`, or `ld.lld`.
|
||||||
|
|
||||||
|
* `--separate-debug-file`, `--separate-debug-file`=_file_:
|
||||||
|
Bundle debug info sections into a separate file instead of embedding them in
|
||||||
|
an output executable or a shared library. mold creates a debug info file in
|
||||||
|
the background by default, so that you can start running your executable as
|
||||||
|
soon as possible.
|
||||||
|
|
||||||
|
By default, the debug info file is created in the same directory as is the
|
||||||
|
output file, with the `.dbg` file extension. That filename is embedded into
|
||||||
|
the output file so that `gdb` can automatically find the debug info file for
|
||||||
|
the output file. For more info about gdb features related to separate debug
|
||||||
|
files, see
|
||||||
|
<https://sourceware.org/gdb/current/onlinedocs/gdb.html/Separate-Debug-Files.html>.
|
||||||
|
|
||||||
|
mold holds a file lock with flock(2) while creating a debug info file in the
|
||||||
|
background.
|
||||||
|
|
||||||
|
If you don't want to create a debug info file in the background, pass the
|
||||||
|
`--no-detach` option.
|
||||||
|
|
||||||
|
* `--shuffle-sections`, `--shuffle-sections`=_number_:
|
||||||
|
Randomize the output by shuffling the order of input sections before
|
||||||
|
assigning them the offsets in the output file. If a _number_ is given, it's
|
||||||
|
used as a seed for the random number generator, so that the linker produces
|
||||||
|
the same output for the same seed. If no seed is given, a random number is
|
||||||
|
used as a seed.
|
||||||
|
|
||||||
|
This option is useful for benchmarking. Modern CPUs are sensitive to a
|
||||||
|
program's memory layout. A seemingly benign change in program layout, such
|
||||||
|
as a small size increase of a function in the middle of a program, can
|
||||||
|
affect the program's performance. Therefore, even if you write new code and
|
||||||
|
get a good benchmark result, it is hard to say whether the new code improves
|
||||||
|
the program's performance; it is possible that the new memory layout happens
|
||||||
|
to perform better.
|
||||||
|
|
||||||
|
By running a benchmark multiple times with randomized memory layouts using
|
||||||
|
`--shuffle-sections`, you can isolate your program's real performance number
|
||||||
|
from the randomness caused by memory layout changes.
|
||||||
|
|
||||||
|
* `--spare-program-headers`=_number_:
|
||||||
|
Append the given number of `PT_NULL` entries to the end of the program
|
||||||
|
header, so that post-link processing tools can easily add new segments by
|
||||||
|
overwriting the null entries.
|
||||||
|
|
||||||
|
Note that ELF requires all `PT_LOAD` segments to be sorted by `p_vaddr`.
|
||||||
|
Therefore, if you add a new LOAD segment, you may need to sort the entire
|
||||||
|
program header.
|
||||||
|
|
||||||
|
* `--stats`:
|
||||||
|
Print input statistics.
|
||||||
|
|
||||||
|
* `--thread-count`=_count_:
|
||||||
|
Use _count_ number of threads.
|
||||||
|
|
||||||
|
* `--threads`, `--no-threads`:
|
||||||
|
Use multiple threads. By default, `mold` uses as many threads as the number of
|
||||||
|
cores or 32, whichever is smaller. The reason it is capped at 32 is because
|
||||||
|
`mold` doesn't scale well beyond that point. To use only one thread, pass
|
||||||
|
`--no-threads` or `--thread-count=1`.
|
||||||
|
|
||||||
|
* `--quick-exit`, `--no-quick-exit`:
|
||||||
|
Use or do not use `quick_exit` to exit.
|
||||||
|
|
||||||
|
* `--zero-to-bss`:
|
||||||
|
Convert all-zero data sections into BSS.
|
||||||
|
|
||||||
|
When this option is enabled, `mold` scans input data sections that are not
|
||||||
|
of type `SHT_NOBITS` and checks whether their contents consist solely of
|
||||||
|
zero bytes. Such sections are then converted into BSS (`SHT_NOBITS`)
|
||||||
|
sections. This reduces the size of the output file, since BSS sections
|
||||||
|
occupy no space in the file image.
|
||||||
|
|
||||||
|
This behavior is especially useful for user-defined sections created with
|
||||||
|
`__attribute__((section(".sectname")))` that contain uninitialized global
|
||||||
|
variables. GCC and Clang do not automatically mark such sections as BSS
|
||||||
|
even if their contents are entirely zero, and instead emit them as regular
|
||||||
|
data sections.
|
||||||
|
|
||||||
|
For example, consider `__attribute__((section(".sectname"))) int vec[256];`.
|
||||||
|
|
||||||
|
By default, this results in a `.sectname` section of type `SHT_PROGBITS`
|
||||||
|
filled with zeros. With `--zero-to-bss`, the linker will recognize it as
|
||||||
|
empty data and convert it to a `SHT_NOBITS` section, reducing the output
|
||||||
|
file size without changing runtime semantics.
|
||||||
|
|
||||||
|
* `-z rewrite-endbr`, `-z norewrite-endbr`:
|
||||||
|
As a security measure, some CPU instruction sets have recently gained a
|
||||||
|
feature to protect control flow integrity by disallowing indirect branches
|
||||||
|
by default. If the feature is enabled, the instruction that is executed
|
||||||
|
immediately after an indirect branch must be an branch target marker
|
||||||
|
instruction, or a CPU-level fault will raise. The marker instruction is also
|
||||||
|
known as "landing pad" instruction, to which indirect branches can land.
|
||||||
|
This feature makes ROP attacks harder to conduct.
|
||||||
|
|
||||||
|
To use the feature, a function whose pointer is taken needs to begin with a
|
||||||
|
landing pad because a function call via a function pointer is compiled to an
|
||||||
|
indirect branch. On the other hand, if a function is called only directly
|
||||||
|
(i.e. referred to only by _direct_ branch instructions), it doesn't have to
|
||||||
|
begin with it.
|
||||||
|
|
||||||
|
By default, the compiler always emits a landing pad at the beginning of each
|
||||||
|
global function because it doesn't know whether or not the function's
|
||||||
|
pointer is taken in another translation unit. As a result, the resulting
|
||||||
|
binary has more attack surface than necessary.
|
||||||
|
|
||||||
|
If `--rewrite-endbr` is given, mold conducts a whole program analysis
|
||||||
|
to identify functions whose addresses are actually taken and rewrites
|
||||||
|
landing pads with no-ops for non-address-taken functions, reducing the
|
||||||
|
attack surface.
|
||||||
|
|
||||||
|
This feature is currently available only on x86-64.
|
||||||
|
|
||||||
|
## GNU-COMPATIBLE OPTIONS
|
||||||
|
|
||||||
|
* `--help`:
|
||||||
|
Report usage information to stdout and exit.
|
||||||
|
|
||||||
|
* `-v`, `--version`:
|
||||||
|
Report version information to stdout.
|
||||||
|
|
||||||
|
* `-V`:
|
||||||
|
Report version and target information to stdout.
|
||||||
|
|
||||||
|
* `-E`, `--export-dynamic`, `--no-export-dynamic`:
|
||||||
|
When creating an executable, using the `-E` option causes all global symbols
|
||||||
|
to be put into the dynamic symbol table, so that the symbols are visible
|
||||||
|
from other ELF modules at runtime.
|
||||||
|
|
||||||
|
By default, or if `--no-export-dynamic` is given, only symbols that are
|
||||||
|
referenced by DSOs at link-time are exported from an executable.
|
||||||
|
|
||||||
|
* `-F` _libname_, `--filter`=_libname_:
|
||||||
|
Set the `DT_FILTER` dynamic section field to _libname_.
|
||||||
|
|
||||||
|
* `-I` _file_, `--dynamic-linker`=_file_, `--no-dynamic-linker`:
|
||||||
|
Set the dynamic linker path to _file_. If no `-I` option is given, or if
|
||||||
|
`--no-dynamic-linker` is given, no dynamic linker path is set to an output
|
||||||
|
file. This is contrary to the GNU linkers which set a default dynamic linker
|
||||||
|
path in that case. This difference doesn't usually make any difference
|
||||||
|
because the compiler driver always passes `-I` to the linker.
|
||||||
|
|
||||||
|
* `-L` _dir_, `--library-path`=_dir_:
|
||||||
|
Add _dir_ to the list of library search paths from which `mold` searches
|
||||||
|
libraries for the `-l` option.
|
||||||
|
|
||||||
|
Unlike the GNU linkers, `mold` does not have default search paths. This
|
||||||
|
difference doesn't usually make any difference because the compiler driver
|
||||||
|
always passes all necessary search paths to the linker.
|
||||||
|
|
||||||
|
* `-M`, `--print-map`:
|
||||||
|
Write a map file to stdout.
|
||||||
|
|
||||||
|
* `-N`, `--omagic`, `--no-omagic`:
|
||||||
|
Force `mold` to emit an output file with an old-fashioned memory layout.
|
||||||
|
First, it makes the first data segment not aligned to a page boundary.
|
||||||
|
Second, text segments are marked as writable if the option is given.
|
||||||
|
|
||||||
|
* `-S`, `--strip-debug`:
|
||||||
|
Omit `.debug_*` sections from the output file.
|
||||||
|
|
||||||
|
* `-T` _file_, `--script`=_file_:
|
||||||
|
Read linker script from _file_.
|
||||||
|
|
||||||
|
* `-X`, `--discard-locals`:
|
||||||
|
Discard temporary local symbols to reduce the sizes of the symbol table and
|
||||||
|
the string table. Temporary local symbols are local symbols starting with
|
||||||
|
`.L`. Compilers usually generate such symbols for unnamed program elements
|
||||||
|
such as string literals or floating-point literals. This is the default;
|
||||||
|
use `--discard-none` to keep temporary local symbols.
|
||||||
|
|
||||||
|
* `--discard-none`:
|
||||||
|
Keep all local symbols in the symbol table, including temporary ones
|
||||||
|
starting with `.L`, except ones in mergeable sections. This restores the
|
||||||
|
default behavior of GNU ld. `mold` and `ld.lld` discard temporary local
|
||||||
|
symbols by default.
|
||||||
|
|
||||||
|
* `-e` _symbol_, `--entry`=_symbol_:
|
||||||
|
|
||||||
|
Use _symbol_ as the entry point symbol instead of the default entry
|
||||||
|
point symbol _start.
|
||||||
|
|
||||||
|
* `-f` _shlib_, `--auxiliary`=_shlib_:
|
||||||
|
Set the `DT_AUXILIARY` dynamic section field to _shlib_.
|
||||||
|
|
||||||
|
* `-h` _libname_, `--soname`=_libname_:
|
||||||
|
Set the `DT_SONAME` dynamic section field to _libname_. This option is used
|
||||||
|
when creating a shared object file. Typically, when you create `libfoo.so`,
|
||||||
|
you want to pass `--soname=foo` to a linker.
|
||||||
|
|
||||||
|
* `-l` _libname_:
|
||||||
|
Search for `lib`_libname_`.so` or `lib`_libname_`.a` from library search
|
||||||
|
paths.
|
||||||
|
|
||||||
|
* `-m` _target_:
|
||||||
|
Choose a _target_.
|
||||||
|
|
||||||
|
* `-o` _file_, `--output`=_file_:
|
||||||
|
Use _file_ as the output file name instead of the default name `a.out`.
|
||||||
|
|
||||||
|
* `-r`, `--relocatable`:
|
||||||
|
Instead of generating an executable or a shared object file, combine input
|
||||||
|
object files to generate another object file that can be used as an input to
|
||||||
|
a linker.
|
||||||
|
|
||||||
|
* `-s`, `--strip-all`:
|
||||||
|
Omit `.symtab` section from the output file.
|
||||||
|
|
||||||
|
* `-u` _symbol_, `--undefined`=_symbol_:
|
||||||
|
If _symbol_ remains as an undefined symbol after reading all object files,
|
||||||
|
and if there is a static archive that contains an object file defining
|
||||||
|
_symbol_, pull out the object file and link it so that the output file
|
||||||
|
contains a definition of _symbol_.
|
||||||
|
|
||||||
|
* `-y` _symbol_, `--trace-symbol`=_symbol_:
|
||||||
|
Trace references to _symbol_.
|
||||||
|
|
||||||
|
* `--Bdynamic`:
|
||||||
|
Link against shared libraries.
|
||||||
|
|
||||||
|
* `--Bstatic`:
|
||||||
|
Do not link against shared libraries.
|
||||||
|
|
||||||
|
* `--Bsymbolic`:
|
||||||
|
When creating a shared library, make global symbols export-only (i.e. do not
|
||||||
|
import the same symbol). As a result, references within a shared library are
|
||||||
|
always resolved locally, negating symbol override at runtime. See "Dynamic
|
||||||
|
symbol resolution" for more information about symbol imports and exports.
|
||||||
|
|
||||||
|
* `--Bsymbolic-functions`:
|
||||||
|
This option has the same effect as `--Bsymbolic` but works only for function
|
||||||
|
symbols. Data symbols remain being both imported and exported.
|
||||||
|
|
||||||
|
* `--Bsymbolic-non-weak`:
|
||||||
|
This option has the same effect as `--Bsymbolic` but works only for non-weak
|
||||||
|
symbols. Weak symbols remain being both imported and exported.
|
||||||
|
|
||||||
|
* `--Bsymbolic-non-weak-functions`:
|
||||||
|
This option has the same effect as `--Bsymbolic` but works only for non-weak
|
||||||
|
function symbols. Data symbols and weak function symbols remain being both
|
||||||
|
imported and exported.
|
||||||
|
|
||||||
|
* `--Bno-symbolic`:
|
||||||
|
Cancel `--Bsymbolic`, `--Bsymbolic-functions`, `--Bsymbolic-non-weak` and
|
||||||
|
`--Bsymbolic-non-weak-functions`.
|
||||||
|
|
||||||
|
* `--Map`=_file_:
|
||||||
|
Write map file to _file_.
|
||||||
|
|
||||||
|
* `--Tbss`=_address_:
|
||||||
|
Alias for `--section-start=.bss=`_address_.
|
||||||
|
|
||||||
|
* `--Tdata`=_address_:
|
||||||
|
Alias for `--section-start=.data=`_address_.
|
||||||
|
|
||||||
|
* `--Ttext`=_address_:
|
||||||
|
Alias for `--section-start=.text=`_address_.
|
||||||
|
|
||||||
|
* `--Ttext-segment`=_address_:
|
||||||
|
Set the address of the first byte of the text segment.
|
||||||
|
|
||||||
|
* `--allow-multiple-definition`:
|
||||||
|
Normally, the linker reports an error if there are more than one definition
|
||||||
|
of a symbol. This option changes the default behavior so that it doesn't
|
||||||
|
report an error for duplicate definitions and instead use the first
|
||||||
|
definition.
|
||||||
|
|
||||||
|
* `--allow-shlib-undefined`, `--no-allow-shlib-undefined`:
|
||||||
|
Even if mold succeeds in linking a main executable without undefined symbol
|
||||||
|
errors, you may still encounter symbol lookup errors at runtime because the
|
||||||
|
dynamic linker cannot find some symbols in shared libraries in any ELF
|
||||||
|
module. This occurs because mold ignores undefined symbols in shared
|
||||||
|
libraries by default.
|
||||||
|
|
||||||
|
If you pass `--no-allow-shlib-undefined`, mold verifies that undefined
|
||||||
|
symbols in shared libraries given to the linker can be resolved at
|
||||||
|
link-time. In other words, this converts the runtime error to a link-time
|
||||||
|
error.
|
||||||
|
|
||||||
|
Note that you need to pass all shared libraries, including indirectly
|
||||||
|
dependent ones, to the linker as arguments for `-l`. If a shared library
|
||||||
|
depends on a library that's not passed to the linker, the verification will
|
||||||
|
be skipped for that file.
|
||||||
|
|
||||||
|
* `--as-needed`, `--no-as-needed`:
|
||||||
|
By default, shared libraries given to the linker are unconditionally added
|
||||||
|
to the list of required libraries in an output file. However, shared
|
||||||
|
libraries after `--as-needed` are added to the list only when at least one
|
||||||
|
symbol is actually used by the output file. In other words, shared libraries
|
||||||
|
after `--as-needed` are not added to the list of needed libraries if they
|
||||||
|
are not needed by a program.
|
||||||
|
|
||||||
|
The `--no-as-needed` option restores the default behavior for subsequent
|
||||||
|
files.
|
||||||
|
|
||||||
|
* `--build-id`=[ `md5` | `sha1` | `sha256` | `fast` | `uuid` | `0x`_hexstring_ | `none` ]:
|
||||||
|
Create a `.note.gnu.build-id` section containing a byte string to uniquely
|
||||||
|
identify an output file. `sha256` compute a 256-bit cryptographic hash of an
|
||||||
|
output file and set it to build-id. `md5` and `sha1` compute the same hash
|
||||||
|
but truncate it to 128 and 160 bits, respectively, before setting it to
|
||||||
|
build-id. `uuid` sets a random 128-bit UUID. `0x`_hexstring_ sets
|
||||||
|
_hexstring_. `fast` is a synonym for `sha256`.
|
||||||
|
|
||||||
|
* `--build-id`:
|
||||||
|
Synonym for `--build-id=sha256`.
|
||||||
|
|
||||||
|
* `--no-build-id`:
|
||||||
|
Synonym for `--build-id=none`.
|
||||||
|
|
||||||
|
* `--compress-debug-sections`=[ `zlib` | `zlib-gabi` | `zlib:`_N_ | `zstd` | `zstd:`_N_ | `none` ]:
|
||||||
|
Compress DWARF debug info (`.debug_*` sections) using the zlib or zstd
|
||||||
|
compression algorithm. `zlib-gabi` is an alias for `zlib`. `zlib:`_N_
|
||||||
|
selects the zlib compression level, where _N_ is between 0 and 9 (0
|
||||||
|
means no compression), and `zstd:`_N_ selects the zstd compression
|
||||||
|
level, where _N_ is between 1 and 22. Higher levels achieve better
|
||||||
|
compression ratios but are slower. `zlib` is equivalent to `zlib:1`
|
||||||
|
and `zstd` is equivalent to `zstd:3`.
|
||||||
|
|
||||||
|
* `--defsym`=_symbol_=_value_:
|
||||||
|
Define _symbol_ as an alias for _value_.
|
||||||
|
|
||||||
|
_value_ is either an integer (in decimal or hexadecimal with `0x` prefix) or
|
||||||
|
a symbol name. If an integer is given as a value, _symbol_ is defined as an
|
||||||
|
absolute symbol with the given value.
|
||||||
|
|
||||||
|
* `--default-symver`:
|
||||||
|
Use soname as a symbol version and append that version to all symbols.
|
||||||
|
|
||||||
|
* `--demangle`, `--no-demangle`:
|
||||||
|
Demangle C++ and Rust symbols in log messages.
|
||||||
|
|
||||||
|
* `--dependency-file`=_file_:
|
||||||
|
Write a dependency file to _file_. The contents of the written file is
|
||||||
|
readable by make(1), which defines only one rule with the linker's output
|
||||||
|
file as a target and all input files as its prerequisites. Users are
|
||||||
|
expected to include the generated dependency file into a Makefile to
|
||||||
|
automate the dependency management. This option is analogous to the
|
||||||
|
compiler's `-MM -MF` options.
|
||||||
|
|
||||||
|
* `--dynamic-list`=_file_:
|
||||||
|
Read a list of dynamic symbols from _file_. Same as
|
||||||
|
`--export-dynamic-symbol-list`, except that it implies `--Bsymbolic`. If
|
||||||
|
_file_ does not exist in the current directory, it is searched from library
|
||||||
|
search paths for the sake of compatibility with GNU ld.
|
||||||
|
|
||||||
|
* `--eh-frame-hdr`, `--no-eh-frame-hdr`:
|
||||||
|
Create `.eh_frame_hdr` section.
|
||||||
|
|
||||||
|
* `--emit-relocs`:
|
||||||
|
The linker usually "consumes" relocation sections. That is, the linker
|
||||||
|
applies relocations to other sections, and relocation sections themselves
|
||||||
|
are discarded.
|
||||||
|
|
||||||
|
The `--emit-relocs` instructs the linker to leave relocation sections in the
|
||||||
|
output file. Some post-link binary analysis or optimization tools such as
|
||||||
|
LLVM Bolt need them.
|
||||||
|
|
||||||
|
* `--enable-new-dtags`, `--disable-new-dtags`:
|
||||||
|
By default, `mold` emits `DT_RUNPATH` for `--rpath`. If you pass
|
||||||
|
`--disable-new-dtags`, `mold` emits `DT_RPATH` for `--rpath` instead.
|
||||||
|
|
||||||
|
* `--execute-only`:
|
||||||
|
|
||||||
|
Traditionally, setting the executable bit to 1 for a memory page implies
|
||||||
|
that the page also become readable, which allows machine code to be read
|
||||||
|
as data at runtime. That is actually what an attacker often does after
|
||||||
|
gaining a limited control of a process to find pieces of machine code
|
||||||
|
they can use to gain the full control of the process. As a mitigation,
|
||||||
|
recent processors including some ARM64 ones allows "execute-only" pages.
|
||||||
|
If a page is execute-only, you can call a function there as long as you
|
||||||
|
know its address but can't read it as data.
|
||||||
|
|
||||||
|
This option marks text segments as execute-only by setting just the "X"
|
||||||
|
bit instead of "RX". Note that on most systems, the absence of the "R"
|
||||||
|
bit in the text segment serves just as a hint. If you run a program
|
||||||
|
linked with `--execute-only` on a processor that doesn't support
|
||||||
|
execute-only pages, your executable will likely still function normally,
|
||||||
|
but the text segment will remain readable.
|
||||||
|
|
||||||
|
* `--exclude-libs`=_libraries_ ...:
|
||||||
|
Mark all symbols in the given _libraries_ hidden.
|
||||||
|
|
||||||
|
* `--export-dynamic-symbol`=_symbol_:
|
||||||
|
Put symbols matching _symbol_ in the dynamic symbol table. _symbol_ may be a
|
||||||
|
glob pattern in the same syntax as for the `--export-dynamic-symbol-list` or
|
||||||
|
`--version-script` options.
|
||||||
|
|
||||||
|
* `--export-dynamic-symbol-list`=_file_:
|
||||||
|
Read a list of dynamic symbols from _file_.
|
||||||
|
|
||||||
|
* `--fatal-warnings`, `--no-fatal-warnings`:
|
||||||
|
Treat warnings as errors.
|
||||||
|
|
||||||
|
* `--fini`=_symbol_:
|
||||||
|
Call _symbol_ at unload-time.
|
||||||
|
|
||||||
|
* `--gc-sections`, `--no-gc-sections`:
|
||||||
|
Remove unreferenced sections.
|
||||||
|
|
||||||
|
* `--gdb-index`:
|
||||||
|
Create a `.gdb_index` section to speed up GNU debugger. To use this, you
|
||||||
|
need to compile source files with the `-ggnu-pubnames` compiler flag.
|
||||||
|
|
||||||
|
* `--hash-style`=[ `sysv` | `gnu` | `both` | `none` ]:
|
||||||
|
Set hash style.
|
||||||
|
|
||||||
|
* `--icf`=[ `safe` | `all` | `none` ], `--no-icf`:
|
||||||
|
It is not uncommon for a program to contain many identical functions that
|
||||||
|
differ only in name. For example, a C++ template `std::vector` is very
|
||||||
|
likely to be instantiated to the identical code for `std::vector<int>` and
|
||||||
|
`std::vector<unsigned>` because the container cares only about the size of
|
||||||
|
the parameter type. Identical Code Folding (ICF) is a size optimization to
|
||||||
|
identify and merge such identical functions.
|
||||||
|
|
||||||
|
If `--icf=all` is given, `mold` tries to merge all identical functions. This
|
||||||
|
reduces the size of the output most, but it is not a "safe" optimization. It
|
||||||
|
is guaranteed in C and C++ that two pointers pointing two different
|
||||||
|
functions will never be equal, but `--icf=all` breaks that assumption as two
|
||||||
|
identical functions have the same address after merging. So a care must be
|
||||||
|
taken when you use this flag that your program does not depend on the
|
||||||
|
function pointer uniqueness.
|
||||||
|
|
||||||
|
`--icf=safe` is a flag to merge functions only when it is safe to do so.
|
||||||
|
That is, if a program does not take an address of a function, it is safe to
|
||||||
|
merge that function with other function, as you cannot compare a function
|
||||||
|
pointer with something else without taking an address of a function.
|
||||||
|
|
||||||
|
`--icf=safe` needs to be used with a compiler that supports `.llvm_addrsig`
|
||||||
|
section which contains the information as to what symbols are address-taken.
|
||||||
|
LLVM/Clang supports that section by default. Since GCC does not support it
|
||||||
|
yet, you cannot use `--icf=safe` with GCC (it doesn't do any harm but can't
|
||||||
|
optimize at all.)
|
||||||
|
|
||||||
|
`--icf=none` and `--no-icf` disables ICF.
|
||||||
|
|
||||||
|
* `--ignore-data-address-equality`:
|
||||||
|
Make ICF to merge not only functions but also data. This option should be
|
||||||
|
used in combination with `--icf=all`.
|
||||||
|
|
||||||
|
* `--image-base`=_addr_:
|
||||||
|
Set the base address to _addr_.
|
||||||
|
|
||||||
|
* `--init`=_symbol_:
|
||||||
|
Call _symbol_ at load-time.
|
||||||
|
|
||||||
|
* `--no-undefined`:
|
||||||
|
Report undefined symbols (even with `--shared`).
|
||||||
|
|
||||||
|
* `--noinhibit-exec`:
|
||||||
|
Create an output file even if errors occur.
|
||||||
|
|
||||||
|
* `--package-metadata`=_percent-encoded-string_:
|
||||||
|
Embed a specified 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.
|
||||||
|
|
||||||
|
An argument to this option is treated as percent-encoded and decoded
|
||||||
|
before being inserted into the section, allowing you to avoid the use of
|
||||||
|
the comma (`,`) character in the argument. This is useful because the
|
||||||
|
compiler replaces all occurrences of commas in `-Wl,` with spaces before
|
||||||
|
forwarding them to the linker. Note that `mold` always interprets the
|
||||||
|
argument as percent-encoded, so you also need to escape all occurrences
|
||||||
|
of `%` as `%25`.
|
||||||
|
|
||||||
|
* `--pack-dyn-relocs`=[ `relr` | `android` | `android+relr` | `none` ]:
|
||||||
|
Compress dynamic relocations in the output file.
|
||||||
|
|
||||||
|
If `relr` is specified, all `R_*_RELATIVE` relocations are put into
|
||||||
|
`.relr.dyn` section instead of `.rel.dyn` or `.rela.dyn` section. Since
|
||||||
|
`.relr.dyn` section uses a space-efficient encoding scheme, specifying this
|
||||||
|
flag can reduce the size of the output. This is typically most effective for
|
||||||
|
position-independent executable.
|
||||||
|
|
||||||
|
If `android` is specified, all dynamic relocations are encoded in Android's
|
||||||
|
packed relocation format (APS2) and stored in the `.rel.dyn` or `.rela.dyn`
|
||||||
|
section, whose section type is changed to `SHT_ANDROID_REL` or
|
||||||
|
`SHT_ANDROID_RELA`. The dynamic table is updated to use `DT_ANDROID_REL`
|
||||||
|
/ `DT_ANDROID_RELA` and their `SZ` variants in place of the standard tags.
|
||||||
|
|
||||||
|
`android+relr` combines both: `R_*_RELATIVE` relocations go to `.relr.dyn`
|
||||||
|
and the rest are APS2-encoded. This is the configuration used by most
|
||||||
|
Android system binaries.
|
||||||
|
|
||||||
|
Note that a runtime loader has to support `.relr.dyn` to run executables or
|
||||||
|
shared libraries linked with `--pack-dyn-relocs=relr`. As of 2026, glibc
|
||||||
|
(since 2.36), musl (since 1.2.4), Android, ChromeOS, and Fuchsia all
|
||||||
|
support it. The APS2 format, on the other hand, is only handled by
|
||||||
|
Android's bionic loader; the encoder itself is target-agnostic, but the
|
||||||
|
produced binary can only be loaded on platforms where bionic (or a
|
||||||
|
compatible loader) handles `DT_ANDROID_REL(A)`.
|
||||||
|
|
||||||
|
* `--pie`, `--pic-executable`, `--no-pie`, `--no-pic-executable`:
|
||||||
|
Create a position-independent executable.
|
||||||
|
|
||||||
|
* `--print-gc-sections`, `--no-print-gc-sections`:
|
||||||
|
Print removed unreferenced sections.
|
||||||
|
|
||||||
|
* `--print-icf-sections`, `--no-print-icf-sections`:
|
||||||
|
Print folded identical sections.
|
||||||
|
|
||||||
|
* `--push-state`, `--pop-state`:
|
||||||
|
`--push-state` saves the current values of `--as-needed`, `--whole-archive`,
|
||||||
|
`--static`, and `--start-lib`. The saved values can be restored by
|
||||||
|
pop-state.
|
||||||
|
|
||||||
|
`--push-state` and `--pop-state` pairs can nest.
|
||||||
|
|
||||||
|
These options are useful when you want to construct linker command line
|
||||||
|
options programmatically. For example, if you want to link `libfoo.so` by
|
||||||
|
as-needed basis but don't want to change the global state of `--as-needed`,
|
||||||
|
you can append `--push-state --as-needed -lfoo --pop-state` to the linker
|
||||||
|
command line options.
|
||||||
|
|
||||||
|
* `--relax, --no-relax`:
|
||||||
|
Rewrite machine instructions with more efficient ones for some relocations.
|
||||||
|
The feature is enabled by default.
|
||||||
|
|
||||||
|
* `--require-defined`=_symbol_:
|
||||||
|
Like `--undefined`, except the new symbol must be defined by the end of the
|
||||||
|
link.
|
||||||
|
|
||||||
|
* `--retain-symbols-file`=_file_:
|
||||||
|
Keep only symbols listed in _file_. _file_ is a text file containing a
|
||||||
|
symbol name on each line. `mold` discards all local symbols as well as
|
||||||
|
global symbol that are not in _file_. Note that this option removes symbols
|
||||||
|
only from `.symtab` section and does not affect `.dynsym` section, which is
|
||||||
|
used for dynamic linking.
|
||||||
|
|
||||||
|
* `--rpath`=_dir_:
|
||||||
|
Add _dir_ to runtime search paths.
|
||||||
|
|
||||||
|
* `--section-start`=_section_=_address_:
|
||||||
|
Set _address_ to section. _address_ is a hexadecimal number that may start
|
||||||
|
with an optional `0x`.
|
||||||
|
|
||||||
|
* `--shared`, `--Bshareable`:
|
||||||
|
Create a share library.
|
||||||
|
|
||||||
|
* `--spare-dynamic-tags`=_number_:
|
||||||
|
Append the given number of `DT_NULL` entries to the end of the `.dynamic`
|
||||||
|
section, so that post-link processing tools can easily add new dynamic tags
|
||||||
|
by overwriting the null entries.
|
||||||
|
|
||||||
|
* `--start-lib`, `--end-lib`:
|
||||||
|
Handle object files between `--start-lib` and `--end-lib` as if they were in
|
||||||
|
an archive file. That means object files between them are linked only when
|
||||||
|
they are needed to resolve undefined symbols. The options are useful if you
|
||||||
|
want to link object files only when they are needed but want to avoid the
|
||||||
|
overhead of running ar(3).
|
||||||
|
|
||||||
|
* `--static`:
|
||||||
|
Do not link against shared libraries.
|
||||||
|
|
||||||
|
* `--sysroot`=_dir_:
|
||||||
|
Set target system root directory to _dir_.
|
||||||
|
|
||||||
|
* `--trace`:
|
||||||
|
Print name of each input file.
|
||||||
|
|
||||||
|
* `--undefined-glob`=_pattern_:
|
||||||
|
Synonym for `--undefined`, except that `--undefined-glob` takes a glob
|
||||||
|
pattern instead of just a single symbol name.
|
||||||
|
|
||||||
|
* `--undefined-version`, `--no-undefined-version`:
|
||||||
|
By default, `mold` warns on a symbol specified by a version script or by
|
||||||
|
`--export-dynamic-symbol` if it is not defined. You can silence the warning
|
||||||
|
by `--undefined-version`.
|
||||||
|
|
||||||
|
* `--unique`=_pattern_:
|
||||||
|
Don't merge input sections that match the given glob pattern _pattern_.
|
||||||
|
|
||||||
|
* `--unresolved-symbols`=[ `report-all` | `ignore-all` | `ignore-in-object-files` | `ignore-in-shared-libs` ]:
|
||||||
|
How to handle undefined symbols.
|
||||||
|
|
||||||
|
* `--version-script`=_file_:
|
||||||
|
Read version script from _file_. If _file_ does not exist in the current
|
||||||
|
directory, it is searched from library search paths for the sake of
|
||||||
|
compatibility with GNU ld.
|
||||||
|
|
||||||
|
* `-w`, `--no-warnings`:
|
||||||
|
Suppress warnings and cancel `--fatal-warnings`.
|
||||||
|
|
||||||
|
* `--warn-common`, `--no-warn-common`:
|
||||||
|
Warn about common symbols.
|
||||||
|
|
||||||
|
* `--warn-once`:
|
||||||
|
Only warn once for each undefined symbol instead of warn for each relocation
|
||||||
|
referring an undefined symbol.
|
||||||
|
|
||||||
|
* `--warn-unresolved-symbols`, `--error-unresolved-symbols`:
|
||||||
|
Normally, the linker reports an error for unresolved symbols.
|
||||||
|
`--warn-unresolved-symbols` option turns it into a warning.
|
||||||
|
`--error-unresolved-symbols` option restores the default behavior.
|
||||||
|
|
||||||
|
* `--whole-archive`, `--no-whole-archive`:
|
||||||
|
When archive files (`.a` files) are given to the linker, only object files
|
||||||
|
that are needed to resolve undefined symbols are extracted from them and
|
||||||
|
linked to an output file. `--whole-archive` changes that behavior for
|
||||||
|
subsequent archives so that the linker extracts all object files and links
|
||||||
|
them to an output. For example, if you are creating a shared object file and
|
||||||
|
you want to include all archive members to the output, you should pass
|
||||||
|
`--whole-archive`. `--no-whole-archive` restores the default behavior for
|
||||||
|
subsequent archives.
|
||||||
|
|
||||||
|
* `--wrap`=_symbol_:
|
||||||
|
Make _symbol_ be resolved to `__wrap_`_symbol_. The original symbol can be
|
||||||
|
resolved as `__real_`_symbol_. This option is typically used for wrapping an
|
||||||
|
existing function.
|
||||||
|
|
||||||
|
* `-z cet-report`=[ `warning` | `error` | `none` ]:
|
||||||
|
Intel Control-flow Enforcement Technology (CET) is a new x86 feature
|
||||||
|
available since Tiger Lake which is released in 2020. It defines new
|
||||||
|
instructions to harden security to protect programs from control hijacking
|
||||||
|
attacks. You can tell the compiler to use the feature by specifying the
|
||||||
|
`-fcf-protection` flag.
|
||||||
|
|
||||||
|
`-z cet-report` flag is used to make sure that all object files were
|
||||||
|
compiled with a correct `-fcf-protection` flag. If `warning` or `error` are
|
||||||
|
given, `mold` prints out a warning or an error message if an object file was
|
||||||
|
not compiled with the compiler flag.
|
||||||
|
|
||||||
|
`mold` looks for `GNU_PROPERTY_X86_FEATURE_1_IBT` bit and
|
||||||
|
`GNU_PROPERTY_X86_FEATURE_1_SHSTK` bit in `.note.gnu.property` section to
|
||||||
|
determine whether or not an object file was compiled with `-fcf-protection`.
|
||||||
|
|
||||||
|
* `-z now`, `-z lazy`:
|
||||||
|
By default, functions referring to other ELF modules are resolved by the
|
||||||
|
dynamic linker when they are called for the first time. `-z now` marks an
|
||||||
|
executable or a shared library file so that all dynamic symbols are resolved
|
||||||
|
when a file is loaded to memory. `-z lazy` restores the default behavior.
|
||||||
|
|
||||||
|
* `-z origin`:
|
||||||
|
Mark object requiring immediate `$ORIGIN` processing at runtime.
|
||||||
|
|
||||||
|
* `-z ibt`:
|
||||||
|
Turn on `GNU_PROPERTY_X86_FEATURE_1_IBT` bit in `.note.gnu.property` section
|
||||||
|
to indicate that the output uses IBT-enabled PLT. This option implies `-z
|
||||||
|
ibtplt`.
|
||||||
|
|
||||||
|
* `-z ibtplt`:
|
||||||
|
Generate Intel Branch Tracking (IBT)-enabled PLT which is the default on
|
||||||
|
x86-64. This is the default.
|
||||||
|
|
||||||
|
* `-z execstack`, `-z noexecstack`:
|
||||||
|
By default, the pages for the stack area (i.e. the pages where local
|
||||||
|
variables reside) are not executable for security reasons. `-z execstack`
|
||||||
|
makes it executable. `-z noexecstack` restores the default behavior.
|
||||||
|
|
||||||
|
* `-z keep-text-section-prefix`, `-z nokeep-text-section-prefix`:
|
||||||
|
Keep `.text.hot`, `.text.unknown`, `.text.unlikely`, `.text.startup`, and
|
||||||
|
`.text.exit` as separate sections in the final binary instead of merging
|
||||||
|
them as `.text`.
|
||||||
|
|
||||||
|
* `-z rodynamic`:
|
||||||
|
Make the `.dynamic` section read-only.
|
||||||
|
|
||||||
|
* `-z relro`, `-z norelro`:
|
||||||
|
Some sections such as `.dynamic` have to be writable only during a module is
|
||||||
|
being loaded to memory. Once the dynamic linker finishes its job, such
|
||||||
|
sections won't be mutated by anyone. As a security mitigation, it is
|
||||||
|
preferred to make such segments read-only during program execution.
|
||||||
|
|
||||||
|
`-z relro` puts such sections into a special segment called `relro`. The
|
||||||
|
dynamic linker makes a relro segment read-only after it finishes its job.
|
||||||
|
|
||||||
|
By default, `mold` generates a relro segment. `-z norelro` disables the
|
||||||
|
feature.
|
||||||
|
|
||||||
|
* `-z sectionheader`, `-z nosectionheader`:
|
||||||
|
`-z nosectionheader` tell the linker to omit the section header.
|
||||||
|
By default, the linker does not omit the section header.
|
||||||
|
|
||||||
|
* `-z separate-loadable-segments`, `-z separate-code`, `-z noseparate-code`:
|
||||||
|
If one memory page contains multiple segments, the page protection bits are
|
||||||
|
set in such a way that the needed attributes (writable or executable) are
|
||||||
|
satisfied for all segments. This usually happens at a boundary of two
|
||||||
|
segments with two different attributes.
|
||||||
|
|
||||||
|
`separate-loadable-segments` adds paddings between segments with different
|
||||||
|
attributes so that they do not share the same page.
|
||||||
|
|
||||||
|
`separate-code` adds paddings only between executable and non-executable
|
||||||
|
segments. This is the default.
|
||||||
|
|
||||||
|
`noseparate-code` does not add any paddings between segments.
|
||||||
|
|
||||||
|
* `-z defs`, `-z nodefs`:
|
||||||
|
Report undefined symbols (even with `--shared`).
|
||||||
|
|
||||||
|
* `-z shstk`:
|
||||||
|
Enforce shadow stack by turning `GNU_PROPERTY_X86_FEATURE_1_SHSTK` bit in
|
||||||
|
`.note.gnu.property` output section. Shadow stack is part of Intel
|
||||||
|
Control-flow Enforcement Technology (CET), which is available since Tiger
|
||||||
|
Lake (2020).
|
||||||
|
|
||||||
|
* `-z start_stop_visibility`=[ `hidden` | `protected` ]:
|
||||||
|
If a section name is valid as a C identifier (i.e., it matches
|
||||||
|
`/^[_a-zA-Z][_a-zA-Z0-9]*$/`), mold creates `__start_SECNAME` and
|
||||||
|
`__stop_SECNAME` symbols to mark the beginning and end of the section,
|
||||||
|
where `SECNAME` is the section name.
|
||||||
|
|
||||||
|
You can make these marker symbols visible from other ELF modules by passing
|
||||||
|
`-z start_stop_visibility=protected`. Default is `hidden`.
|
||||||
|
|
||||||
|
* `-z text`, `-z notext`, `-z textoff`:
|
||||||
|
`mold` by default reports an error if dynamic relocations are created in
|
||||||
|
read-only sections. If `-z notext` or `-z textoff` are given, `mold` creates
|
||||||
|
such dynamic relocations without reporting an error. `-z text` restores the
|
||||||
|
default behavior.
|
||||||
|
|
||||||
|
* `-z max-page-size`=_number_:
|
||||||
|
Some CPU ISAs support multiple memory page sizes. This option specifies the
|
||||||
|
maximum page size that an output binary can run on. In general, binaries
|
||||||
|
built for a larger page size can run on a system with a smaller page size,
|
||||||
|
but not vice versa. The default value is 4 KiB for i386, x86-64, and RISC-V,
|
||||||
|
and 64 KiB for ARM64.
|
||||||
|
|
||||||
|
* `-z nodefaultlib`:
|
||||||
|
Make the dynamic loader ignore default search paths.
|
||||||
|
|
||||||
|
* `-z nodelete`:
|
||||||
|
Mark DSO non-deletable at runtime.
|
||||||
|
|
||||||
|
* `-z nodlopen`:
|
||||||
|
Mark DSO not available to dlopen(3). This option makes it possible for the
|
||||||
|
linker to optimize thread-local variable accesses by rewriting instructions
|
||||||
|
for some targets.
|
||||||
|
|
||||||
|
* `-z nodump`:
|
||||||
|
Mark DSO not available to dldump(3).
|
||||||
|
|
||||||
|
* `-z nocopyreloc`:
|
||||||
|
Do not create copy relocations.
|
||||||
|
|
||||||
|
* `-z initfirst`:
|
||||||
|
Mark DSO to be initialized first at runtime.
|
||||||
|
|
||||||
|
* `-z interpose`:
|
||||||
|
Mark object to interpose all DSOs but executable.
|
||||||
|
|
||||||
|
* `-(`, `-)`, `-EL`, `-O`_number_, `--dc`, `--dp`, `--end-group`, `--no-add-needed`, `--no-copy-dt-needed-entries`, `--nostdlib`, `--rpath-link=Ar dir`, `--sort-common`, `--sort-section`, `--start-group`, `--warn-constructors`, `--warn-once`, `--fix-cortex-a53-835769`, `--fix-cortex-a53-843419`, `-z combreloc`, `-z common-page-size`, `-z nocombreloc`:
|
||||||
|
Ignored
|
||||||
|
|
||||||
|
## ENVIRONMENT VARIABLES
|
||||||
|
|
||||||
|
* `MOLD_JOBS`:
|
||||||
|
If this variable is set to `1`, only one `mold` process will run at a time.
|
||||||
|
If a new mold process is initiated while another is already active, the new
|
||||||
|
process will wait until the active one completes before starting.
|
||||||
|
|
||||||
|
The primary reason for this environment variable is to minimize peak memory
|
||||||
|
usage. Since mold is designed to operate with high parallelism, running
|
||||||
|
multiple mold instances simultaneously may not be beneficial. If you execute
|
||||||
|
N instances of mold concurrently, it could require N times the time and N
|
||||||
|
times the memory. On the other hand, running them one after the other might
|
||||||
|
still take N times longer, but the peak memory usage would be the same as
|
||||||
|
running just a single instance.
|
||||||
|
|
||||||
|
If your build system invokes multiple linker processes simultaneously and
|
||||||
|
some of them often get killed due to out-of-memory errors, you might
|
||||||
|
consider setting this environment variable to `1` to see if it addresses the
|
||||||
|
OOM issue.
|
||||||
|
|
||||||
|
Currently, any value other than `1` is silently ignored.
|
||||||
|
|
||||||
|
* `MOLD_DEBUG`:
|
||||||
|
If this variable is set to a non-empty string, `mold` embeds its
|
||||||
|
command-line options in the output file's `.comment` section.
|
||||||
|
|
||||||
|
* `MOLD_REPRO`:
|
||||||
|
Setting this variable to a non-empty string has the same effect as passing
|
||||||
|
the `--repro` option.
|
||||||
|
|
||||||
|
## SEE ALSO
|
||||||
|
|
||||||
|
gold(1), ld(1), elf(5), ld.so(8)
|
||||||
|
|
||||||
|
## AUTHOR
|
||||||
|
|
||||||
|
Rui Ueyama <ruiu@cs.stanford.edu>
|
||||||
|
|
||||||
|
## BUGS
|
||||||
|
|
||||||
|
Report bugs to <https://github.com/rui314/mold/issues>.
|
||||||
Executable
+30
@@ -0,0 +1,30 @@
|
|||||||
|
#!/bin/sh
|
||||||
|
set -e
|
||||||
|
|
||||||
|
PREFIX=${PREFIX:-/usr/local}
|
||||||
|
|
||||||
|
srcdir=$(CDPATH= cd "$(dirname "$0")" && pwd)
|
||||||
|
artifact_dir="$srcdir/target/release"
|
||||||
|
|
||||||
|
if [ ! -x "$artifact_dir/mold" ] ||
|
||||||
|
[ ! -f "$artifact_dir/mold-wrapper.so" ]; then
|
||||||
|
echo "install-mold.sh: release artifacts are missing" >&2
|
||||||
|
echo "Run 'cargo build --release' first." >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
bindir="$DESTDIR$PREFIX/bin"
|
||||||
|
libdir="$DESTDIR$PREFIX/lib/mold"
|
||||||
|
libexecdir="$DESTDIR$PREFIX/libexec/mold"
|
||||||
|
mandir="$DESTDIR$PREFIX/share/man/man1"
|
||||||
|
docdir="$DESTDIR$PREFIX/share/doc/mold"
|
||||||
|
|
||||||
|
install -d "$bindir" "$libdir" "$libexecdir" "$mandir" "$docdir"
|
||||||
|
install -m 755 "$artifact_dir/mold" "$bindir"
|
||||||
|
install -m 755 "$artifact_dir/mold-wrapper.so" "$libdir"
|
||||||
|
install -m 644 "$srcdir/docs/mold.1" "$mandir"
|
||||||
|
install -m 644 "$srcdir/LICENSE" "$docdir"
|
||||||
|
|
||||||
|
ln -sf mold "$bindir/ld.mold"
|
||||||
|
ln -sf ../../bin/mold "$libexecdir/ld"
|
||||||
|
ln -sf mold.1 "$mandir/ld.mold.1"
|
||||||
Reference in new issue
Block a user