mold
—
a modern linker
mold |
[ -options ]
objfile ... |
mold
is a faster drop-in replacement for the
default GNU
ld(1).
How to use
mold
See
https://github.com/rui314/mold#how-to-use.
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 despite 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 linker script features. The linker script is an ad-hoc,
over-designed, complex language which we believe needs to be disrupted by a
simpler mechanism. We have a plan to add a replacement for the linker script
to
mold
instead.
Traditionally, Unix linkers are sensitive to the order in which input files
appear on command line. They process input files from the first (left-most)
file to the last (right-most) 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 go 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 semantics, 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 are remain undefined. If you put archive files at the beginning of a
command line, a linker doesn't have any undefined symbol, and thus no object
files will be pulled out from archives.
You can change the processing order by
--start-group
and
--end-group
options, though they make a
linker slower.
mold
as well as LLVM
lld(1) linker take a different approach. They
memorize what symbols can be resolved from archive files instead of forgetting
it 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.
Some Unix linker features are unable to be understood without understanding the
semantics of dynamic symbol resolution. Therefore, even though that's not
specific to
mold
, we'll explain it here.
We use "ELF module" or just "module" as a collective term to
refer 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 construct 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 depending 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 the
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 in the symbol search list provides another
definition of the same symbol.
Let me take
malloc(3) as an example. Assume that
you define your version of
malloc(3) in your main
executable file. Then, all
malloc calls from any
module are resolved to your function instead of that in libc, because the
executable is always at the beginning of the dynamic symbol search list. Note
that even
malloc(3) 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(3) in libc becomes dead
code.
These Unix semantics are tricky and sometimes considered harmful. For example,
assume that you accidentally define
atoi(3) 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 obviously causes
a problem. That is a somewhat surprising consequence for an accidental name
conflict. On the other hand, this semantic is sometimes considered useful
because it allows users to overwrite library functions without recompiling
modules containing them. Whether good or bad, you should keep this semantic in
mind to understand the Unix linkers behaviors.
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 to always
produce the same 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 to which some configurable
values, such as system-dependent library search paths, are hard-coded.
mold
depends only on its command-line
arguments.
-
-
--help
- Report usage information to stdout and exit.
-
-
-v
,
--version
- Report version information to stdout.
-
-
-V
- Report version and target information to stdout.
-
-
-C
dir,
--directory
dir
- Change to dir before doing anything.
-
-
-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 sets a default dynamic linker path in that case. However,
this difference doesn't usually make any difference because the compiler
driver always passes -I
to a
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 the default search paths. This difference doesn't usually make any
difference because the compiler driver always passes all necessary search
paths to a 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 to
not be 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.
-
-
-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 Sylib
foo.so, you
want to pass
--soname
=foo
to a linker.
-
-
-l
libname
- Search for Sylib
libname.so
or Sylib
libname.a
from library search paths.
-
-
-m
[elf_x86_64 |
elf_i386
]
- 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
,
-FL
--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 an 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.
-
-
--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 is always resolved locally, negating symbol override at runtime.
See Dynamic
symbol resolution for more information about symbol imports and
exports.
-
-
--Bsymbolic-functions
- Have the same effect as
--Bsymbolic
but
works only for function symbols. Data symbols remains both imported and
exported.
-
-
--Bno-symbolic
- Cancel
--Bsymbolic
and
--Bsymbolic-functions
.
-
-
--Map
=file
- Write map file to file.
-
-
--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.
-
-
--as-needed
,
--no-as-needed
- By default, shared libraries given to a 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 an object
file. In other words, shared libraries after
--as-needed
are not added to the list
if they are not needed by a program.
The --no-as-needed
option restores the
default behavior for subsequent files.
-
-
--build-id
,
--no-build-id
,
--build-id
=[none
| md5 | sha1 |
sha256 | uuid |
0xhexstring
]
- Create a
.note.gnu.build-id
section containing a
byte string to uniquely identify an output file.
--build-id
and
--build-id
=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.
0xhexstring
sets hexstring.
-
-
--chroot
=dir
- Set dir to root directory.
-
-
--compress-debug-sections
=[none
| zlib | zlib-gabi
| zlib-gnu
]
- Compress DWARF debug info (.debug_* sections)
using the zlib compression algorithm.
-
-
--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++ symbols in log messages.
-
-
--dynamic-list
=file
- Read a list of dynamic symbols from
file.
-
-
--eh-frame-hdr
,
--no-eh-frame-hdr
- Create
.eh_frame_hdr
section.
-
-
--exclude-libs
=libraries...
- Mark all symbols in the given libraries
hidden.
-
-
--fini
=symbol
- Call symbol at unload-time.
-
-
--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.
-
-
--gc-sections
,
--no-gc-sections
- Remove unreferenced sections.
-
-
--hash-style
=[sysv
| gnu |
both
]
- Set hash style.
-
-
--icf
=all,
--no-icf
- Fold identical code.
-
-
--image-base
=addr
- Set the base address to addr.
-
-
--init
=symbol
- Call symbol at load-time.
-
-
--no-undefined
- Report undefined symbols (even with
--shared
).
-
-
--pack-dyn-relocs
=[none
| relr
]
- 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 that flag can reduce the size
of the output. This is typically most effective for position-independent
executable. Note that a runtime loader has to support
.relr.dyn
to run executables or shared libraries
linked with --pack-dyn-relocs=relr
, and
only ChromeOS, Android and Fuchsia support it as of now in 2022.
-
-
--perf
- Print performance statistics.
-
-
--pie
,
--pic-executable
,
--no-pie
,
--no-pic-executable
- Create a position-independent executable.
-
-
--pop-state
- Pop state of flags governing input file handling.
-
-
--preload
- Preload object files.
-
-
--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 of flags governing input file handling
-
-
--quick-exit
,
--no-quick-exit
- Use
quick_exit
to exit.
-
-
--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.
-
-
--repro
- Embed input files into
.repro
section.
-
-
--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 sybmol 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 path.
-
-
--run
command
arg file
...
- Run
command
with
mold
as
/usr/bin/ld.
-
-
--shared
,
--Bshareable
- Create a share library.
-
-
--spare-dynamic-tags
=number
- Reserve given number of tags in
.dynamic
section.
-
-
--static
- Do not link against shared libraries.
-
-
--stats
- Print input statistics.
-
-
--sysroot
=dir
- Set target system root directory to
dir.
-
-
--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 the
smallest. The reason why it is capped to 32 is because
mold
doesn't scale well beyond that
point. To use only one thread, pass
--no-threads
or
--thread-count
=1.
-
-
--trace
- Print name of each input file.
-
-
--unique
=pattern
- Don't merge input sections that match
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.
-
-
--warn-common
-
--no-warn-common
- Warn about common symbols.
-
-
--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 a
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 a linker extracts all object files and
link 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 to 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
=none
| warning |
error
- 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 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 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 loaded 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.
IBT is part of Intel Control-flow Enforcement Technology (CET). IBT is a new
x86 feature available since Tiger Lake which is released in 2020. If IBT
is enabled, all indirect branch instructions have to branch to a so-called
"landing pad" instruction. Landing pad itself is a no-op, but it
works as a marker that branching to that instruction is expected. If
there's no landing pad after branch, the CPU raises an exception. This
mechanism makes ROP attacks difficult.
Since PLT can be used as an indirect branch target, we need a different
instruction sequence for IBT-enabled PLT. If -z
ibtplt is specified,
mold
generates
PLT entries that start with a landing pad. The size of IBT-enabled PLT is
24 bytes as opposed to 16 bytes regular PLT.
-
-
-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.
-
-
-z
relro
,
-z
norelro
- Some sections such as
.dynamic
have to
be writable only during an executable or a shared library file 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
section called relro
. The dynamic
linker make a relro segment read-only after it finishes its job.
By default, mold
generates a
relro segment.
-z
norelro
disables the feature.
-
-
-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 needed attributes (writable or executable) are
satisifed 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. This is the default.
separate-code
adds paddings only between
executable and non-executable segments.
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
notext
,
-z
textoff
,
-z
text
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
- Some CPU ISAs support multiple different memory page sizes. This option
specifies the maximum page size that an output binary can run on. If you
specify a large value, the output can run on both large and small page
systems, but it wastes a bit of memory at page boundaries on systems with
small pages.
The default value is 4 KiB for i386 and x86-64, and 64 KiB for ARM64.
-
-
-z
nodefaultlib
- Make the dynamic loader to ignore default search paths.
-
-
-z
nodelete
- Mark DSO non-deletable at runtime.
-
-
-z
nodlopen
- Mark DSO not available to dlopen(3).
-
-
-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.
gold(1),
ld(1),
ld.so(8)
Rui Ueyama
<
ruiu@cs.stanford.edu>
Report bugs to
https://github.com/rui314/mold/issues.