Provided by: mold_1.0.3+dfsg-2_amd64 bug

NAME

     mold — a modern linker

SYNOPSIS

     mold [-options] objfile ...

DESCRIPTION

     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.

   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 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.

   Archive symbol resolution
     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.

   Dynamic symbol resolution
     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.

   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 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.

OPTIONS

     --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.

     -Ifile, --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.

     -Ldir, --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, --sonamelibname
             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.

     -llibname
             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.

SEE ALSO

     gold(1), ld(1), ld.so(8)

AUTHORS

     Rui Ueyama <ruiu@cs.stanford.edu>

BUGS

     Report bugs to https://github.com/rui314/mold/issues.