src.conf.5: regen after r368667, GDB retirement

[FreeBSD/FreeBSD.git] / contrib / binutils / ld / ld.7

.Dd 2015-03-02
.Dt LD 7
.Os
.Sh NAME
.Nm ld
.Nd The GNU Linker
.Sh  LD
This file documents the GNU linker ld version "2.17.50 [FreeBSD] 2007-07-03".
.Pp
This document is distributed under the terms of the GNU Free Documentation
License. A copy of the license is included in the section entitled \(lqGNU Free
Documentation License\(rq.
.Pp
.Sh  Overview
.Xr ld
combines a number of object and archive files, relocates their data and ties
up symbol references. Usually the last step in compiling a program is to run
.Xr ld .
.Pp
.Xr ld
accepts Linker Command Language files written in a superset of AT&T's Link
Editor Command Language syntax, to provide explicit and total control over
the linking process.
.Pp
This version of
.Xr ld
uses the general purpose BFD libraries to operate on object files. This allows
.Xr ld
to read, combine, and write object files in many different formats---for example,
COFF or
.Li a.out .
Different formats may be linked together to produce any available kind of
object file.See Section
.Dq BFD ,
for more information.
.Pp
Aside from its flexibility, the GNU linker is more helpful than other linkers
in providing diagnostic information. Many linkers abandon execution immediately
upon encountering an error; whenever possible,
.Xr ld
continues executing, allowing you to identify other errors (or, in some cases,
to get an output file in spite of the error).
.Pp
.Sh  Invocation
The GNU linker
.Xr ld
is meant to cover a broad range of situations, and to be as compatible as
possible with other linkers. As a result, you have many choices to control
its behavior.
.Pp
.Ss  Command Line Options
The linker supports a plethora of command-line options, but in actual practice
few of them are used in any particular context. For instance, a frequent use
of
.Xr ld
is to link standard Unix object files on a standard, supported Unix system.
On such a system, to link a file
.Li hello.o :
.Pp
.Bd -literal -offset indent
ld -o output /lib/crt0.o hello.o -lc
.Ed
.Pp
This tells
.Xr ld
to produce a file called
.Va output
as the result of linking the file
.Li /lib/crt0.o
with
.Li hello.o
and the library
.Li libc.a ,
which will come from the standard search directories. (See the discussion
of the
.Li -l
option below.)
.Pp
Some of the command-line options to
.Xr ld
may be specified at any point in the command line. However, options which
refer to files, such as
.Li -l
or
.Li -T ,
cause the file to be read at the point at which the option appears in the
command line, relative to the object files and other file options. Repeating
non-file options with a different argument will either have no further effect,
or override prior occurrences (those further to the left on the command line)
of that option. Options which may be meaningfully specified more than once
are noted in the descriptions below.
.Pp
Non-option arguments are object files or archives which are to be linked together.
They may follow, precede, or be mixed in with command-line options, except
that an object file argument may not be placed between an option and its argument.
.Pp
Usually the linker is invoked with at least one object file, but you can specify
other forms of binary input files using
.Li -l ,
.Li -R ,
and the script command language. If
.Em no
binary input files at all are specified, the linker does not produce any output,
and issues the message
.Li No input files .
.Pp
If the linker cannot recognize the format of an object file, it will assume
that it is a linker script. A script specified in this way augments the main
linker script used for the link (either the default linker script or the one
specified by using
.Li -T ) .
This feature permits the linker to link against a file which appears to be
an object or an archive, but actually merely defines some symbol values, or
uses
.Li INPUT
or
.Li GROUP
to load other objects. Note that specifying a script in this way merely augments
the main linker script; use the
.Li -T
option to replace the default linker script entirely.See Section
.Dq Scripts .
.Pp
For options whose names are a single letter, option arguments must either
follow the option letter without intervening whitespace, or be given as separate
arguments immediately following the option that requires them.
.Pp
For options whose names are multiple letters, either one dash or two can precede
the option name; for example,
.Li -trace-symbol
and
.Li --trace-symbol
are equivalent. Note---there is one exception to this rule. Multiple letter
options that start with a lower case 'o' can only be preceded by two dashes.
This is to reduce confusion with the
.Li -o
option. So for example
.Li -omagic
sets the output file name to
.Li magic
whereas
.Li --omagic
sets the NMAGIC flag on the output.
.Pp
Arguments to multiple-letter options must either be separated from the option
name by an equals sign, or be given as separate arguments immediately following
the option that requires them. For example,
.Li --trace-symbol foo
and
.Li --trace-symbol=foo
are equivalent. Unique abbreviations of the names of multiple-letter options
are accepted.
.Pp
Note---if the linker is being invoked indirectly, via a compiler driver (e.g.
.Li gcc )
then all the linker command line options should be prefixed by
.Li -Wl,
(or whatever is appropriate for the particular compiler driver) like this:
.Pp
.Bd -literal -offset indent
  gcc -Wl,--startgroup foo.o bar.o -Wl,--endgroup
.Ed
.Pp
This is important, because otherwise the compiler driver program may silently
drop the linker options, resulting in a bad link.
.Pp
Here is a table of the generic command line switches accepted by the GNU linker:
.Pp
.Bl -tag -width Ds
.It  @ Va file
Read command-line options from
.Va file .
The options read are inserted in place of the original @
.Va file
option. If
.Va file
does not exist, or cannot be read, then the option will be treated literally,
and not removed.
.Pp
Options in
.Va file
are separated by whitespace. A whitespace character may be included in an
option by surrounding the entire option in either single or double quotes.
Any character (including a backslash) may be included by prefixing the character
to be included with a backslash. The
.Va file
may itself contain additional @
.Va file
options; any such options will be processed recursively.
.Pp
.It  -a Va keyword
This option is supported for HP/UX compatibility. The
.Va keyword
argument must be one of the strings
.Li archive ,
.Li shared ,
or
.Li default .
.Li -aarchive
is functionally equivalent to
.Li -Bstatic ,
and the other two keywords are functionally equivalent to
.Li -Bdynamic .
This option may be used any number of times.
.Pp
.It  -A Va architecture
.It  --architecture= Va architecture
In the current release of
.Xr ld ,
this option is useful only for the Intel 960 family of architectures. In that
.Xr ld
configuration, the
.Va architecture
argument identifies the particular architecture in the 960 family, enabling
some safeguards and modifying the archive-library search path.See Section
.Dq i960 ,
for details.
.Pp
Future releases of
.Xr ld
may support similar functionality for other architecture families.
.Pp
.It  -b Va input-format
.It  --format= Va input-format
.Xr ld
may be configured to support more than one kind of object file. If your
.Xr ld
is configured this way, you can use the
.Li -b
option to specify the binary format for input object files that follow this
option on the command line. Even when
.Xr ld
is configured to support alternative object formats, you don't usually need
to specify this, as
.Xr ld
should be configured to expect as a default input format the most usual format
on each machine.
.Va input-format
is a text string, the name of a particular format supported by the BFD libraries.
(You can list the available binary formats with
.Li objdump -i . )
See Section.Dq BFD .
.Pp
You may want to use this option if you are linking files with an unusual binary
format. You can also use
.Li -b
to switch formats explicitly (when linking object files of different formats),
by including
.Li -b Va input-format
before each group of object files in a particular format.
.Pp
The default format is taken from the environment variable
.Li GNUTARGET .
See Section.Dq Environment .
You can also define the input format from a script, using the command
.Li TARGET ;
see Format Commands.
.Pp
.It  -c Va MRI-commandfile
.It  --mri-script= Va MRI-commandfile
For compatibility with linkers produced by MRI,
.Xr ld
accepts script files written in an alternate, restricted command language,
described in MRI,,MRI Compatible Script Files. Introduce MRI script files
with the option
.Li -c ;
use the
.Li -T
option to run linker scripts written in the general-purpose
.Xr ld
scripting language. If
.Va MRI-cmdfile
does not exist,
.Xr ld
looks for it in the directories specified by any
.Li -L
options.
.Pp
.It  -d
.It  -dc
.It  -dp
These three options are equivalent; multiple forms are supported for compatibility
with other linkers. They assign space to common symbols even if a relocatable
output file is specified (with
.Li -r ) .
The script command
.Li FORCE_COMMON_ALLOCATION
has the same effect.See Section
.Dq Miscellaneous Commands .
.Pp
.It  -e Va entry
.It  --entry= Va entry
Use
.Va entry
as the explicit symbol for beginning execution of your program, rather than
the default entry point. If there is no symbol named
.Va entry ,
the linker will try to parse
.Va entry
as a number, and use that as the entry address (the number will be interpreted
in base 10; you may use a leading
.Li 0x
for base 16, or a leading
.Li 0
for base 8).See Section
.Dq Entry Point ,
for a discussion of defaults and other ways of specifying the entry point.
.Pp
.It  --exclude-libs Va lib, Va lib,...
Specifies a list of archive libraries from which symbols should not be automatically
exported. The library names may be delimited by commas or colons. Specifying
.Li --exclude-libs ALL
excludes symbols in all archive libraries from automatic export. This option
is available only for the i386 PE targeted port of the linker and for ELF
targeted ports. For i386 PE, symbols explicitly listed in a .def file are
still exported, regardless of this option. For ELF targeted ports, symbols
affected by this option will be treated as hidden.
.Pp
.It  -E
.It  --export-dynamic
When creating a dynamically linked executable, add all symbols to the dynamic
symbol table. The dynamic symbol table is the set of symbols which are visible
from dynamic objects at run time.
.Pp
If you do not use this option, the dynamic symbol table will normally contain
only those symbols which are referenced by some dynamic object mentioned in
the link.
.Pp
If you use
.Li dlopen
to load a dynamic object which needs to refer back to the symbols defined
by the program, rather than some other dynamic object, then you will probably
need to use this option when linking the program itself.
.Pp
You can also use the dynamic list to control what symbols should be added
to the dynamic symbol table if the output format supports it. See the description
of
.Li --dynamic-list .
.Pp
.It  -EB
Link big-endian objects. This affects the default output format.
.Pp
.It  -EL
Link little-endian objects. This affects the default output format.
.Pp
.It  -f
.It  --auxiliary Va name
When creating an ELF shared object, set the internal DT_AUXILIARY field to
the specified name. This tells the dynamic linker that the symbol table of
the shared object should be used as an auxiliary filter on the symbol table
of the shared object
.Va name .
.Pp
If you later link a program against this filter object, then, when you run
the program, the dynamic linker will see the DT_AUXILIARY field. If the dynamic
linker resolves any symbols from the filter object, it will first check whether
there is a definition in the shared object
.Va name .
If there is one, it will be used instead of the definition in the filter object.
The shared object
.Va name
need not exist. Thus the shared object
.Va name
may be used to provide an alternative implementation of certain functions,
perhaps for debugging or for machine specific performance.
.Pp
This option may be specified more than once. The DT_AUXILIARY entries will
be created in the order in which they appear on the command line.
.Pp
.It  -F Va name
.It  --filter Va name
When creating an ELF shared object, set the internal DT_FILTER field to the
specified name. This tells the dynamic linker that the symbol table of the
shared object which is being created should be used as a filter on the symbol
table of the shared object
.Va name .
.Pp
If you later link a program against this filter object, then, when you run
the program, the dynamic linker will see the DT_FILTER field. The dynamic
linker will resolve symbols according to the symbol table of the filter object
as usual, but it will actually link to the definitions found in the shared
object
.Va name .
Thus the filter object can be used to select a subset of the symbols provided
by the object
.Va name .
.Pp
Some older linkers used the
.Op -F
option throughout a compilation toolchain for specifying object-file format
for both input and output object files. The GNU linker uses other mechanisms
for this purpose: the
.Op -b ,
.Op --format ,
.Op --oformat
options, the
.Li TARGET
command in linker scripts, and the
.Li GNUTARGET
environment variable. The GNU linker will ignore the
.Op -F
option when not creating an ELF shared object.
.Pp
.It  -fini Va name
When creating an ELF executable or shared object, call NAME when the executable
or shared object is unloaded, by setting DT_FINI to the address of the function.
By default, the linker uses
.Li _fini
as the function to call.
.Pp
.It  -g
Ignored. Provided for compatibility with other tools.
.Pp
.It  -G Va value
.It  --gpsize= Va value
Set the maximum size of objects to be optimized using the GP register to
.Va size .
This is only meaningful for object file formats such as MIPS ECOFF which supports
putting large and small objects into different sections. This is ignored for
other object file formats.
.Pp
.It  -h Va name
.It  -soname= Va name
When creating an ELF shared object, set the internal DT_SONAME field to the
specified name. When an executable is linked with a shared object which has
a DT_SONAME field, then when the executable is run the dynamic linker will
attempt to load the shared object specified by the DT_SONAME field rather
than the using the file name given to the linker.
.Pp
.It  -i
Perform an incremental link (same as option
.Li -r ) .
.Pp
.It  -init Va name
When creating an ELF executable or shared object, call NAME when the executable
or shared object is loaded, by setting DT_INIT to the address of the function.
By default, the linker uses
.Li _init
as the function to call.
.Pp
.It  -l Va namespec
.It  --library= Va namespec
Add the archive or object file specified by
.Va namespec
to the list of files to link. This option may be used any number of times.
If
.Va namespec
is of the form
.Pa : Va filename ,
.Xr ld
will search the library path for a file called
.Va filename ,
otherise it will search the library path for a file called
.Pa lib Va namespec.a .
.Pp
On systems which support shared libraries,
.Xr ld
may also search for files other than
.Pa lib Va namespec.a .
Specifically, on ELF and SunOS systems,
.Xr ld
will search a directory for a library called
.Pa lib Va namespec.so
before searching for one called
.Pa lib Va namespec.a .
(By convention, a
.Li .so
extension indicates a shared library.) Note that this behavior does not apply
to
.Pa : Va filename ,
which always specifies a file called
.Va filename .
.Pp
The linker will search an archive only once, at the location where it is specified
on the command line. If the archive defines a symbol which was undefined in
some object which appeared before the archive on the command line, the linker
will include the appropriate file(s) from the archive. However, an undefined
symbol in an object appearing later on the command line will not cause the
linker to search the archive again.
.Pp
See the
.Op -(
option for a way to force the linker to search archives multiple times.
.Pp
You may list the same archive multiple times on the command line.
.Pp
This type of archive searching is standard for Unix linkers. However, if you
are using
.Xr ld
on AIX, note that it is different from the behaviour of the AIX linker.
.Pp
.It  -L Va searchdir
.It  --library-path= Va searchdir
Add path
.Va searchdir
to the list of paths that
.Xr ld
will search for archive libraries and
.Xr ld
control scripts. You may use this option any number of times. The directories
are searched in the order in which they are specified on the command line.
Directories specified on the command line are searched before the default
directories. All
.Op -L
options apply to all
.Op -l
options, regardless of the order in which the options appear.
.Pp
If
.Va searchdir
begins with
.Li = ,
then the
.Li =
will be replaced by the
.Em sysroot prefix ,
a path specified when the linker is configured.
.Pp
The default set of paths searched (without being specified with
.Li -L )
depends on which emulation mode
.Xr ld
is using, and in some cases also on how it was configured.See Section
.Dq Environment .
.Pp
The paths can also be specified in a link script with the
.Li SEARCH_DIR
command. Directories specified this way are searched at the point in which
the linker script appears in the command line.
.Pp
.It  -m Va emulation
Emulate the
.Va emulation
linker. You can list the available emulations with the
.Li --verbose
or
.Li -V
options.
.Pp
If the
.Li -m
option is not used, the emulation is taken from the
.Li LDEMULATION
environment variable, if that is defined.
.Pp
Otherwise, the default emulation depends upon how the linker was configured.
.Pp
.It  -M
.It  --print-map
Print a link map to the standard output. A link map provides information about
the link, including the following:
.Pp
.Bl -bullet
.It
Where object files are mapped into memory.
.It
How common symbols are allocated.
.It
All archive members included in the link, with a mention of the symbol which
caused the archive member to be brought in.
.It
The values assigned to symbols.
.Pp
Note - symbols whose values are computed by an expression which involves a
reference to a previous value of the same symbol may not have correct result
displayed in the link map. This is because the linker discards intermediate
results and only retains the final value of an expression. Under such circumstances
the linker will display the final value enclosed by square brackets. Thus
for example a linker script containing:
.Pp
.Bd -literal -offset indent
   foo = 1
   foo = foo * 4
   foo = foo + 8
.Ed
.Pp
will produce the following output in the link map if the
.Op -M
option is used:
.Pp
.Bd -literal -offset indent
   0x00000001                foo = 0x1
   [0x0000000c]                foo = (foo * 0x4)
   [0x0000000c]                foo = (foo + 0x8)
.Ed
.Pp
See Expressions for more information about expressions in linker scripts.
.El
.Pp
.It  -n
.It  --nmagic
Turn off page alignment of sections, and mark the output as
.Li NMAGIC
if possible.
.Pp
.It  -N
.It  --omagic
Set the text and data sections to be readable and writable. Also, do not page-align
the data segment, and disable linking against shared libraries. If the output
format supports Unix style magic numbers, mark the output as
.Li OMAGIC .
Note: Although a writable text section is allowed for PE-COFF targets, it
does not conform to the format specification published by Microsoft.
.Pp
.It  --no-omagic
This option negates most of the effects of the
.Op -N
option. It sets the text section to be read-only, and forces the data segment
to be page-aligned. Note - this option does not enable linking against shared
libraries. Use
.Op -Bdynamic
for this.
.Pp
.It  -o Va output
.It  --output= Va output
Use
.Va output
as the name for the program produced by
.Xr ld ;
if this option is not specified, the name
.Pa a.out
is used by default. The script command
.Li OUTPUT
can also specify the output file name.
.Pp
.It  -O Va level
If
.Va level
is a numeric values greater than zero
.Xr ld
optimizes the output. This might take significantly longer and therefore probably
should only be enabled for the final binary.
.Pp
.It  -q
.It  --emit-relocs
Leave relocation sections and contents in fully linked executables. Post link
analysis and optimization tools may need this information in order to perform
correct modifications of executables. This results in larger executables.
.Pp
This option is currently only supported on ELF platforms.
.Pp
.It  --force-dynamic
Force the output file to have dynamic sections. This option is specific to
VxWorks targets.
.Pp
.It  -r
.It  --relocatable
Generate relocatable output---i.e., generate an output file that can in turn
serve as input to
.Xr ld .
This is often called
.Em partial linking .
As a side effect, in environments that support standard Unix magic numbers,
this option also sets the output file's magic number to
.Li OMAGIC .
If this option is not specified, an absolute file is produced. When linking
C++ programs, this option
.Em will not
resolve references to constructors; to do that, use
.Li -Ur .
.Pp
When an input file does not have the same format as the output file, partial
linking is only supported if that input file does not contain any relocations.
Different output formats can have further restrictions; for example some
.Li a.out
-based formats do not support partial linking with input files in other formats
at all.
.Pp
This option does the same thing as
.Li -i .
.Pp
.It  -R Va filename
.It  --just-symbols= Va filename
Read symbol names and their addresses from
.Va filename ,
but do not relocate it or include it in the output. This allows your output
file to refer symbolically to absolute locations of memory defined in other
programs. You may use this option more than once.
.Pp
For compatibility with other ELF linkers, if the
.Op -R
option is followed by a directory name, rather than a file name, it is treated
as the
.Op -rpath
option.
.Pp
.It  -s
.It  --strip-all
Omit all symbol information from the output file.
.Pp
.It  -S
.It  --strip-debug
Omit debugger symbol information (but not all symbols) from the output file.
.Pp
.It  -t
.It  --trace
Print the names of the input files as
.Xr ld
processes them.
.Pp
.It  -T Va scriptfile
.It  --script= Va scriptfile
Use
.Va scriptfile
as the linker script. This script replaces
.Xr ld
\&'s default linker script (rather than adding to it), so
.Va commandfile
must specify everything necessary to describe the output file.See Section
.Dq Scripts .
If
.Va scriptfile
does not exist in the current directory,
.Li ld
looks for it in the directories specified by any preceding
.Li -L
options. Multiple
.Li -T
options accumulate.
.Pp
.It  -dT Va scriptfile
.It  --default-script= Va scriptfile
Use
.Va scriptfile
as the default linker script.See Section
.Dq Scripts .
.Pp
This option is similar to the
.Op --script
option except that processing of the script is delayed until after the rest
of the command line has been processed. This allows options placed after the
.Op --default-script
option on the command line to affect the behaviour of the linker script, which
can be important when the linker command line cannot be directly controlled
by the user. (eg because the command line is being constructed by another
tool, such as
.Li gcc ) .
.Pp
.It  -u Va symbol
.It  --undefined= Va symbol
Force
.Va symbol
to be entered in the output file as an undefined symbol. Doing this may, for
example, trigger linking of additional modules from standard libraries.
.Li -u
may be repeated with different option arguments to enter additional undefined
symbols. This option is equivalent to the
.Li EXTERN
linker script command.
.Pp
.It  -Ur
For anything other than C++ programs, this option is equivalent to
.Li -r :
it generates relocatable output---i.e., an output file that can in turn serve
as input to
.Xr ld .
When linking C++ programs,
.Li -Ur
.Em does
resolve references to constructors, unlike
.Li -r .
It does not work to use
.Li -Ur
on files that were themselves linked with
.Li -Ur ;
once the constructor table has been built, it cannot be added to. Use
.Li -Ur
only for the last partial link, and
.Li -r
for the others.
.Pp
.It  --unique[= Va SECTION]
Creates a separate output section for every input section matching
.Va SECTION ,
or if the optional wildcard
.Va SECTION
argument is missing, for every orphan input section. An orphan section is
one not specifically mentioned in a linker script. You may use this option
multiple times on the command line; It prevents the normal merging of input
sections with the same name, overriding output section assignments in a linker
script.
.Pp
.It  -v
.It  --version
.It  -V
Display the version number for
.Xr ld .
The
.Op -V
option also lists the supported emulations.
.Pp
.It  -x
.It  --discard-all
Delete all local symbols.
.Pp
.It  -X
.It  --discard-locals
Delete all temporary local symbols. (These symbols start with system-specific
local label prefixes, typically
.Li .L
for ELF systems or
.Li L
for traditional a.out systems.)
.Pp
.It  -y Va symbol
.It  --trace-symbol= Va symbol
Print the name of each linked file in which
.Va symbol
appears. This option may be given any number of times. On many systems it
is necessary to prepend an underscore.
.Pp
This option is useful when you have an undefined symbol in your link but don't
know where the reference is coming from.
.Pp
.It  -Y Va path
Add
.Va path
to the default library search path. This option exists for Solaris compatibility.
.Pp
.It  -z Va keyword
The recognized keywords are:
.Bl -tag -width Ds
.It  combreloc
Combines multiple reloc sections and sorts them to make dynamic symbol lookup
caching possible.
.Pp
.It  defs
Disallows undefined symbols in object files. Undefined symbols in shared libraries
are still allowed.
.Pp
.It  execstack
Marks the object as requiring executable stack.
.Pp
.It  initfirst
This option is only meaningful when building a shared object. It marks the
object so that its runtime initialization will occur before the runtime initialization
of any other objects brought into the process at the same time. Similarly
the runtime finalization of the object will occur after the runtime finalization
of any other objects.
.Pp
.It  interpose
Marks the object that its symbol table interposes before all symbols but the
primary executable.
.Pp
.It  lazy
When generating an executable or shared library, mark it to tell the dynamic
linker to defer function call resolution to the point when the function is
called (lazy binding), rather than at load time. Lazy binding is the default.
.Pp
.It  loadfltr
Marks the object that its filters be processed immediately at runtime.
.Pp
.It  muldefs
Allows multiple definitions.
.Pp
.It  nocombreloc
Disables multiple reloc sections combining.
.Pp
.It  nocopyreloc
Disables production of copy relocs.
.Pp
.It  nodefaultlib
Marks the object that the search for dependencies of this object will ignore
any default library search paths.
.Pp
.It  nodelete
Marks the object shouldn't be unloaded at runtime.
.Pp
.It  nodlopen
Marks the object not available to
.Li dlopen .
.Pp
.It  nodump
Marks the object can not be dumped by
.Li dldump .
.Pp
.It  noexecstack
Marks the object as not requiring executable stack.
.Pp
.It  norelro
Don't create an ELF
.Li PT_GNU_RELRO
segment header in the object.
.Pp
.It  now
When generating an executable or shared library, mark it to tell the dynamic
linker to resolve all symbols when the program is started, or when the shared
library is linked to using dlopen, instead of deferring function call resolution
to the point when the function is first called.
.Pp
.It  origin
Marks the object may contain $ORIGIN.
.Pp
.It  relro
Create an ELF
.Li PT_GNU_RELRO
segment header in the object.
.Pp
.It  max-page-size= Va value
Set the emulation maximum page size to
.Va value .
.Pp
.It  common-page-size= Va value
Set the emulation common page size to
.Va value .
.Pp
.El
Other keywords are ignored for Solaris compatibility.
.Pp
.It  -( Va archives -)
.It  --start-group Va archives --end-group
The
.Va archives
should be a list of archive files. They may be either explicit file names,
or
.Li -l
options.
.Pp
The specified archives are searched repeatedly until no new undefined references
are created. Normally, an archive is searched only once in the order that
it is specified on the command line. If a symbol in that archive is needed
to resolve an undefined symbol referred to by an object in an archive that
appears later on the command line, the linker would not be able to resolve
that reference. By grouping the archives, they all be searched repeatedly
until all possible references are resolved.
.Pp
Using this option has a significant performance cost. It is best to use it
only when there are unavoidable circular references between two or more archives.
.Pp
.It  --accept-unknown-input-arch
.It  --no-accept-unknown-input-arch
Tells the linker to accept input files whose architecture cannot be recognised.
The assumption is that the user knows what they are doing and deliberately
wants to link in these unknown input files. This was the default behaviour
of the linker, before release 2.14. The default behaviour from release 2.14
onwards is to reject such input files, and so the
.Li --accept-unknown-input-arch
option has been added to restore the old behaviour.
.Pp
.It  --as-needed
.It  --no-as-needed
This option affects ELF DT_NEEDED tags for dynamic libraries mentioned on
the command line after the
.Op --as-needed
option. Normally, the linker will add a DT_NEEDED tag for each dynamic library
mentioned on the command line, regardless of whether the library is actually
needed.
.Op --as-needed
causes DT_NEEDED tags to only be emitted for libraries that satisfy some symbol
reference from regular objects which is undefined at the point that the library
was linked.
.Op --no-as-needed
restores the default behaviour.
.Pp
.It  --add-needed
.It  --no-add-needed
This option affects the treatment of dynamic libraries from ELF DT_NEEDED
tags in dynamic libraries mentioned on the command line after the
.Op --no-add-needed
option. Normally, the linker will add a DT_NEEDED tag for each dynamic library
from DT_NEEDED tags.
.Op --no-add-needed
causes DT_NEEDED tags will never be emitted for those libraries from DT_NEEDED
tags.
.Op --add-needed
restores the default behaviour.
.Pp
.It  -assert Va keyword
This option is ignored for SunOS compatibility.
.Pp
.It  -Bdynamic
.It  -dy
.It  -call_shared
Link against dynamic libraries. This is only meaningful on platforms for which
shared libraries are supported. This option is normally the default on such
platforms. The different variants of this option are for compatibility with
various systems. You may use this option multiple times on the command line:
it affects library searching for
.Op -l
options which follow it.
.Pp
.It  -Bgroup
Set the
.Li DF_1_GROUP
flag in the
.Li DT_FLAGS_1
entry in the dynamic section. This causes the runtime linker to handle lookups
in this object and its dependencies to be performed only inside the group.
.Op --unresolved-symbols=report-all
is implied. This option is only meaningful on ELF platforms which support
shared libraries.
.Pp
.It  -Bstatic
.It  -dn
.It  -non_shared
.It  -static
Do not link against shared libraries. This is only meaningful on platforms
for which shared libraries are supported. The different variants of this option
are for compatibility with various systems. You may use this option multiple
times on the command line: it affects library searching for
.Op -l
options which follow it. This option also implies
.Op --unresolved-symbols=report-all .
This option can be used with
.Op -shared .
Doing so means that a shared library is being created but that all of the
library's external references must be resolved by pulling in entries from
static libraries.
.Pp
.It  -Bsymbolic
When creating a shared library, bind references to global symbols to the definition
within the shared library, if any. Normally, it is possible for a program
linked against a shared library to override the definition within the shared
library. This option is only meaningful on ELF platforms which support shared
libraries.
.Pp
.It  -Bsymbolic-functions
When creating a shared library, bind references to global function symbols
to the definition within the shared library, if any. This option is only meaningful
on ELF platforms which support shared libraries.
.Pp
.It  --dynamic-list= Va dynamic-list-file
Specify the name of a dynamic list file to the linker. This is typically used
when creating shared libraries to specify a list of global symbols whose references
shouldn't be bound to the definition within the shared library, or creating
dynamically linked executables to specify a list of symbols which should be
added to the symbol table in the executable. This option is only meaningful
on ELF platforms which support shared libraries.
.Pp
The format of the dynamic list is the same as the version node without scope
and node name. See VERSION for more information.
.Pp
.It  --dynamic-list-data
Include all global data symbols to the dynamic list.
.Pp
.It  --dynamic-list-cpp-new
Provide the builtin dynamic list for C++ operator new and delete. It is mainly
useful for building shared libstdc++.
.Pp
.It  --dynamic-list-cpp-typeinfo
Provide the builtin dynamic list for C++ runtime type identification.
.Pp
.It  --check-sections
.It  --no-check-sections
Asks the linker
.Em not
to check section addresses after they have been assigned to see if there are
any overlaps. Normally the linker will perform this check, and if it finds
any overlaps it will produce suitable error messages. The linker does know
about, and does make allowances for sections in overlays. The default behaviour
can be restored by using the command line switch
.Op --check-sections .
.Pp
.It  --cref
Output a cross reference table. If a linker map file is being generated, the
cross reference table is printed to the map file. Otherwise, it is printed
on the standard output.
.Pp
The format of the table is intentionally simple, so that it may be easily
processed by a script if necessary. The symbols are printed out, sorted by
name. For each symbol, a list of file names is given. If the symbol is defined,
the first file listed is the location of the definition. The remaining files
contain references to the symbol.
.Pp
.It  --no-define-common
This option inhibits the assignment of addresses to common symbols. The script
command
.Li INHIBIT_COMMON_ALLOCATION
has the same effect.See Section
.Dq Miscellaneous Commands .
.Pp
The
.Li --no-define-common
option allows decoupling the decision to assign addresses to Common symbols
from the choice of the output file type; otherwise a non-Relocatable output
type forces assigning addresses to Common symbols. Using
.Li --no-define-common
allows Common symbols that are referenced from a shared library to be assigned
addresses only in the main program. This eliminates the unused duplicate space
in the shared library, and also prevents any possible confusion over resolving
to the wrong duplicate when there are many dynamic modules with specialized
search paths for runtime symbol resolution.
.Pp
.It  --defsym Va symbol= Va expression
Create a global symbol in the output file, containing the absolute address
given by
.Va expression .
You may use this option as many times as necessary to define multiple symbols
in the command line. A limited form of arithmetic is supported for the
.Va expression
in this context: you may give a hexadecimal constant or the name of an existing
symbol, or use
.Li +
and
.Li -
to add or subtract hexadecimal constants or symbols. If you need more elaborate
expressions, consider using the linker command language from a script (see Section
.Dq Assignments ) .
.Em Note:
there should be no white space between
.Va symbol ,
the equals sign (\(lq=\(rq), and
.Va expression .
.Pp
.It  --demangle[= Va style]
.It  --no-demangle
These options control whether to demangle symbol names in error messages and
other output. When the linker is told to demangle, it tries to present symbol
names in a readable fashion: it strips leading underscores if they are used
by the object file format, and converts C++ mangled symbol names into user
readable names. Different compilers have different mangling styles. The optional
demangling style argument can be used to choose an appropriate demangling
style for your compiler. The linker will demangle by default unless the environment
variable
.Li COLLECT_NO_DEMANGLE
is set. These options may be used to override the default.
.Pp
.It  --dynamic-linker Va file
Set the name of the dynamic linker. This is only meaningful when generating
dynamically linked ELF executables. The default dynamic linker is normally
correct; don't use this unless you know what you are doing.
.Pp
.It  --fatal-warnings
Treat all warnings as errors.
.Pp
.It  --force-exe-suffix
Make sure that an output file has a .exe suffix.
.Pp
If a successfully built fully linked output file does not have a
.Li .exe
or
.Li .dll
suffix, this option forces the linker to copy the output file to one of the
same name with a
.Li .exe
suffix. This option is useful when using unmodified Unix makefiles on a Microsoft
Windows host, since some versions of Windows won't run an image unless it
ends in a
.Li .exe
suffix.
.Pp
.It  --gc-sections
.It  --no-gc-sections
Enable garbage collection of unused input sections. It is ignored on targets
that do not support this option. This option is not compatible with
.Li -r
or
.Li --emit-relocs .
The default behaviour (of not performing this garbage collection) can be restored
by specifying
.Li --no-gc-sections
on the command line.
.Pp
.It  --print-gc-sections
.It  --no-print-gc-sections
List all sections removed by garbage collection. The listing is printed on
stderr. This option is only effective if garbage collection has been enabled
via the
.Li --gc-sections )
option. The default behaviour (of not listing the sections that are removed)
can be restored by specifying
.Li --no-print-gc-sections
on the command line.
.Pp
.It  --help
Print a summary of the command-line options on the standard output and exit.
.Pp
.It  --target-help
Print a summary of all target specific options on the standard output and
exit.
.Pp
.It  -Map Va mapfile
Print a link map to the file
.Va mapfile .
See the description of the
.Op -M
option, above.
.Pp
.It  --no-keep-memory
.Xr ld
normally optimizes for speed over memory usage by caching the symbol tables
of input files in memory. This option tells
.Xr ld
to instead optimize for memory usage, by rereading the symbol tables as necessary.
This may be required if
.Xr ld
runs out of memory space while linking a large executable.
.Pp
.It  --no-undefined
.It  -z defs
Report unresolved symbol references from regular object files. This is done
even if the linker is creating a non-symbolic shared library. The switch
.Op --[no-]allow-shlib-undefined
controls the behaviour for reporting unresolved references found in shared
libraries being linked in.
.Pp
.It  --allow-multiple-definition
.It  -z muldefs
Normally when a symbol is defined multiple times, the linker will report a
fatal error. These options allow multiple definitions and the first definition
will be used.
.Pp
.It  --allow-shlib-undefined
.It  --no-allow-shlib-undefined
Allows (the default) or disallows undefined symbols in shared libraries. This
switch is similar to
.Op --no-undefined
except that it determines the behaviour when the undefined symbols are in
a shared library rather than a regular object file. It does not affect how
undefined symbols in regular object files are handled.
.Pp
The reason that
.Op --allow-shlib-undefined
is the default is that the shared library being specified at link time may
not be the same as the one that is available at load time, so the symbols
might actually be resolvable at load time. Plus there are some systems, (eg
BeOS) where undefined symbols in shared libraries is normal. (The kernel patches
them at load time to select which function is most appropriate for the current
architecture. This is used for example to dynamically select an appropriate
memset function). Apparently it is also normal for HPPA shared libraries to
have undefined symbols.
.Pp
.It  --no-undefined-version
Normally when a symbol has an undefined version, the linker will ignore it.
This option disallows symbols with undefined version and a fatal error will
be issued instead.
.Pp
.It  --default-symver
Create and use a default symbol version (the soname) for unversioned exported
symbols.
.Pp
.It  --default-imported-symver
Create and use a default symbol version (the soname) for unversioned imported
symbols.
.Pp
.It  --no-warn-mismatch
Normally
.Xr ld
will give an error if you try to link together input files that are mismatched
for some reason, perhaps because they have been compiled for different processors
or for different endiannesses. This option tells
.Xr ld
that it should silently permit such possible errors. This option should only
be used with care, in cases when you have taken some special action that ensures
that the linker errors are inappropriate.
.Pp
.It  --no-warn-search-mismatch
Normally
.Xr ld
will give a warning if it finds an incompatible library during a library search.
This option silences the warning.
.Pp
.It  --no-whole-archive
Turn off the effect of the
.Op --whole-archive
option for subsequent archive files.
.Pp
.It  --noinhibit-exec
Retain the executable output file whenever it is still usable. Normally, the
linker will not produce an output file if it encounters errors during the
link process; it exits without writing an output file when it issues any error
whatsoever.
.Pp
.It  -nostdlib
Only search library directories explicitly specified on the command line.
Library directories specified in linker scripts (including linker scripts
specified on the command line) are ignored.
.Pp
.It  --oformat Va output-format
.Xr ld
may be configured to support more than one kind of object file. If your
.Xr ld
is configured this way, you can use the
.Li --oformat
option to specify the binary format for the output object file. Even when
.Xr ld
is configured to support alternative object formats, you don't usually need
to specify this, as
.Xr ld
should be configured to produce as a default output format the most usual
format on each machine.
.Va output-format
is a text string, the name of a particular format supported by the BFD libraries.
(You can list the available binary formats with
.Li objdump -i . )
The script command
.Li OUTPUT_FORMAT
can also specify the output format, but this option overrides it.See Section
.Dq BFD .
.Pp
.It  -pie
.It  --pic-executable
Create a position independent executable. This is currently only supported
on ELF platforms. Position independent executables are similar to shared libraries
in that they are relocated by the dynamic linker to the virtual address the
OS chooses for them (which can vary between invocations). Like normal dynamically
linked executables they can be executed and symbols defined in the executable
cannot be overridden by shared libraries.
.Pp
.It  -qmagic
This option is ignored for Linux compatibility.
.Pp
.It  -Qy
This option is ignored for SVR4 compatibility.
.Pp
.It  --relax
An option with machine dependent effects. This option is only supported on
a few targets.See Section
.Dq H8/300 .
See Section.Dq i960 .
See Section.Dq Xtensa .
See Section.Dq M68HC11/68HC12 .
See Section.Dq PowerPC ELF32 .
.Pp
On some platforms, the
.Li --relax
option performs global optimizations that become possible when the linker
resolves addressing in the program, such as relaxing address modes and synthesizing
new instructions in the output object file.
.Pp
On some platforms these link time global optimizations may make symbolic debugging
of the resulting executable impossible. This is known to be the case for the
Matsushita MN10200 and MN10300 family of processors.
.Pp
On platforms where this is not supported,
.Li --relax
is accepted, but ignored.
.Pp
.It  --retain-symbols-file Va filename
Retain
.Em only
the symbols listed in the file
.Va filename ,
discarding all others.
.Va filename
is simply a flat file, with one symbol name per line. This option is especially
useful in environments (such as VxWorks) where a large global symbol table
is accumulated gradually, to conserve run-time memory.
.Pp
.Li --retain-symbols-file
does
.Em not
discard undefined symbols, or symbols needed for relocations.
.Pp
You may only specify
.Li --retain-symbols-file
once in the command line. It overrides
.Li -s
and
.Li -S .
.Pp
.It  -rpath Va dir
Add a directory to the runtime library search path. This is used when linking
an ELF executable with shared objects. All
.Op -rpath
arguments are concatenated and passed to the runtime linker, which uses them
to locate shared objects at runtime. The
.Op -rpath
option is also used when locating shared objects which are needed by shared
objects explicitly included in the link; see the description of the
.Op -rpath-link
option. If
.Op -rpath
is not used when linking an ELF executable, the contents of the environment
variable
.Li LD_RUN_PATH
will be used if it is defined.
.Pp
The
.Op -rpath
option may also be used on SunOS. By default, on SunOS, the linker will form
a runtime search patch out of all the
.Op -L
options it is given. If a
.Op -rpath
option is used, the runtime search path will be formed exclusively using the
.Op -rpath
options, ignoring the
.Op -L
options. This can be useful when using gcc, which adds many
.Op -L
options which may be on NFS mounted file systems.
.Pp
For compatibility with other ELF linkers, if the
.Op -R
option is followed by a directory name, rather than a file name, it is treated
as the
.Op -rpath
option.
.Pp
.It  -rpath-link Va DIR
When using ELF or SunOS, one shared library may require another. This happens
when an
.Li ld -shared
link includes a shared library as one of the input files.
.Pp
When the linker encounters such a dependency when doing a non-shared, non-relocatable
link, it will automatically try to locate the required shared library and
include it in the link, if it is not included explicitly. In such a case,
the
.Op -rpath-link
option specifies the first set of directories to search. The
.Op -rpath-link
option may specify a sequence of directory names either by specifying a list
of names separated by colons, or by appearing multiple times.
.Pp
This option should be used with caution as it overrides the search path that
may have been hard compiled into a shared library. In such a case it is possible
to use unintentionally a different search path than the runtime linker would
do.
.Pp
The linker uses the following search paths to locate required shared libraries:
.Bl -enum
.It
Any directories specified by
.Op -rpath-link
options.
.It
Any directories specified by
.Op -rpath
options. The difference between
.Op -rpath
and
.Op -rpath-link
is that directories specified by
.Op -rpath
options are included in the executable and used at runtime, whereas the
.Op -rpath-link
option is only effective at link time. Searching
.Op -rpath
in this way is only supported by native linkers and cross linkers which have
been configured with the
.Op --with-sysroot
option.
.It
On an ELF system, if the
.Op -rpath
and
.Li rpath-link
options were not used, search the contents of the environment variable
.Li LD_RUN_PATH .
It is for the native linker only.
.It
On SunOS, if the
.Op -rpath
option was not used, search any directories specified using
.Op -L
options.
.It
For a native linker, the contents of the environment variable
.Li LD_LIBRARY_PATH .
.It
For a native ELF linker, the directories in
.Li DT_RUNPATH
or
.Li DT_RPATH
of a shared library are searched for shared libraries needed by it. The
.Li DT_RPATH
entries are ignored if
.Li DT_RUNPATH
entries exist.
.It
The default directories, normally
.Pa /lib
and
.Pa /usr/lib .
.It
For a native linker on an ELF system, if the file
.Pa /etc/ld.so.conf
exists, the list of directories found in that file.
.El
.Pp
If the required shared library is not found, the linker will issue a warning
and continue with the link.
.Pp
.It  -shared
.It  -Bshareable
Create a shared library. This is currently only supported on ELF, XCOFF and
SunOS platforms. On SunOS, the linker will automatically create a shared library
if the
.Op -e
option is not used and there are undefined symbols in the link.
.Pp
.It  --sort-common
This option tells
.Xr ld
to sort the common symbols by size when it places them in the appropriate
output sections. First come all the one byte symbols, then all the two byte,
then all the four byte, and then everything else. This is to prevent gaps
between symbols due to alignment constraints.
.Pp
.It  --sort-section name
This option will apply
.Li SORT_BY_NAME
to all wildcard section patterns in the linker script.
.Pp
.It  --sort-section alignment
This option will apply
.Li SORT_BY_ALIGNMENT
to all wildcard section patterns in the linker script.
.Pp
.It  --split-by-file [ Va size]
Similar to
.Op --split-by-reloc
but creates a new output section for each input file when
.Va size
is reached.
.Va size
defaults to a size of 1 if not given.
.Pp
.It  --split-by-reloc [ Va count]
Tries to creates extra sections in the output file so that no single output
section in the file contains more than
.Va count
relocations. This is useful when generating huge relocatable files for downloading
into certain real time kernels with the COFF object file format; since COFF
cannot represent more than 65535 relocations in a single section. Note that
this will fail to work with object file formats which do not support arbitrary
sections. The linker will not split up individual input sections for redistribution,
so if a single input section contains more than
.Va count
relocations one output section will contain that many relocations.
.Va count
defaults to a value of 32768.
.Pp
.It  --stats
Compute and display statistics about the operation of the linker, such as
execution time and memory usage.
.Pp
.It  --sysroot= Va directory
Use
.Va directory
as the location of the sysroot, overriding the configure-time default. This
option is only supported by linkers that were configured using
.Op --with-sysroot .
.Pp
.It  --traditional-format
For some targets, the output of
.Xr ld
is different in some ways from the output of some existing linker. This switch
requests
.Xr ld
to use the traditional format instead.
.Pp
For example, on SunOS,
.Xr ld
combines duplicate entries in the symbol string table. This can reduce the
size of an output file with full debugging information by over 30 percent.
Unfortunately, the SunOS
.Li dbx
program can not read the resulting program (
.Li gdb
has no trouble). The
.Li --traditional-format
switch tells
.Xr ld
to not combine duplicate entries.
.Pp
.It  --section-start Va sectionname= Va org
Locate a section in the output file at the absolute address given by
.Va org .
You may use this option as many times as necessary to locate multiple sections
in the command line.
.Va org
must be a single hexadecimal integer; for compatibility with other linkers,
you may omit the leading
.Li 0x
usually associated with hexadecimal values.
.Em Note:
there should be no white space between
.Va sectionname ,
the equals sign (\(lq=\(rq), and
.Va org .
.Pp
.It  -Tbss Va org
.It  -Tdata Va org
.It  -Ttext Va org
Same as --section-start, with
.Li .bss ,
.Li .data
or
.Li .text
as the
.Va sectionname .
.Pp
.It  --unresolved-symbols= Va method
Determine how to handle unresolved symbols. There are four possible values
for
.Li method :
.Pp
.Bl -tag -width Ds
.It  ignore-all
Do not report any unresolved symbols.
.Pp
.It  report-all
Report all unresolved symbols. This is the default.
.Pp
.It  ignore-in-object-files
Report unresolved symbols that are contained in shared libraries, but ignore
them if they come from regular object files.
.Pp
.It  ignore-in-shared-libs
Report unresolved symbols that come from regular object files, but ignore
them if they come from shared libraries. This can be useful when creating
a dynamic binary and it is known that all the shared libraries that it should
be referencing are included on the linker's command line.
.El
.Pp
The behaviour for shared libraries on their own can also be controlled by
the
.Op --[no-]allow-shlib-undefined
option.
.Pp
Normally the linker will generate an error message for each reported unresolved
symbol but the option
.Op --warn-unresolved-symbols
can change this to a warning.
.Pp
.It  --dll-verbose
.It  --verbose
Display the version number for
.Xr ld
and list the linker emulations supported. Display which input files can and
cannot be opened. Display the linker script being used by the linker.
.Pp
.It  --version-script= Va version-scriptfile
Specify the name of a version script to the linker. This is typically used
when creating shared libraries to specify additional information about the
version hierarchy for the library being created. This option is only meaningful
on ELF platforms which support shared libraries.See Section
.Dq VERSION .
.Pp
.It  --warn-common
Warn when a common symbol is combined with another common symbol or with a
symbol definition. Unix linkers allow this somewhat sloppy practise, but linkers
on some other operating systems do not. This option allows you to find potential
problems from combining global symbols. Unfortunately, some C libraries use
this practise, so you may get some warnings about symbols in the libraries
as well as in your programs.
.Pp
There are three kinds of global symbols, illustrated here by C examples:
.Pp
.Bl -tag -width Ds
.It  int i = 1;
A definition, which goes in the initialized data section of the output file.
.Pp
.It  extern int i;
An undefined reference, which does not allocate space. There must be either
a definition or a common symbol for the variable somewhere.
.Pp
.It  int i;
A common symbol. If there are only (one or more) common symbols for a variable,
it goes in the uninitialized data area of the output file. The linker merges
multiple common symbols for the same variable into a single symbol. If they
are of different sizes, it picks the largest size. The linker turns a common
symbol into a declaration, if there is a definition of the same variable.
.El
.Pp
The
.Li --warn-common
option can produce five kinds of warnings. Each warning consists of a pair
of lines: the first describes the symbol just encountered, and the second
describes the previous symbol encountered with the same name. One or both
of the two symbols will be a common symbol.
.Pp
.Bl -enum
.It
Turning a common symbol into a reference, because there is already a definition
for the symbol.
.Bd -literal -offset indent
file(section): warning: common of `symbol'
   overridden by definition
file(section): warning: defined here
.Ed
.Pp
.It
Turning a common symbol into a reference, because a later definition for the
symbol is encountered. This is the same as the previous case, except that
the symbols are encountered in a different order.
.Bd -literal -offset indent
file(section): warning: definition of `symbol'
   overriding common
file(section): warning: common is here
.Ed
.Pp
.It
Merging a common symbol with a previous same-sized common symbol.
.Bd -literal -offset indent
file(section): warning: multiple common
   of `symbol'
file(section): warning: previous common is here
.Ed
.Pp
.It
Merging a common symbol with a previous larger common symbol.
.Bd -literal -offset indent
file(section): warning: common of `symbol'
   overridden by larger common
file(section): warning: larger common is here
.Ed
.Pp
.It
Merging a common symbol with a previous smaller common symbol. This is the
same as the previous case, except that the symbols are encountered in a different
order.
.Bd -literal -offset indent
file(section): warning: common of `symbol'
   overriding smaller common
file(section): warning: smaller common is here
.Ed
.El
.Pp
.It  --warn-constructors
Warn if any global constructors are used. This is only useful for a few object
file formats. For formats like COFF or ELF, the linker can not detect the
use of global constructors.
.Pp
.It  --warn-multiple-gp
Warn if multiple global pointer values are required in the output file. This
is only meaningful for certain processors, such as the Alpha. Specifically,
some processors put large-valued constants in a special section. A special
register (the global pointer) points into the middle of this section, so that
constants can be loaded efficiently via a base-register relative addressing
mode. Since the offset in base-register relative mode is fixed and relatively
small (e.g., 16 bits), this limits the maximum size of the constant pool.
Thus, in large programs, it is often necessary to use multiple global pointer
values in order to be able to address all possible constants. This option
causes a warning to be issued whenever this case occurs.
.Pp
.It  --warn-once
Only warn once for each undefined symbol, rather than once per module which
refers to it.
.Pp
.It  --warn-section-align
Warn if the address of an output section is changed because of alignment.
Typically, the alignment will be set by an input section. The address will
only be changed if it not explicitly specified; that is, if the
.Li SECTIONS
command does not specify a start address for the section (see Section
.Dq SECTIONS ) .
.Pp
.It  --warn-shared-textrel
Warn if the linker adds a DT_TEXTREL to a shared object.
.Pp
.It  --warn-unresolved-symbols
If the linker is going to report an unresolved symbol (see the option
.Op --unresolved-symbols )
it will normally generate an error. This option makes it generate a warning
instead.
.Pp
.It  --error-unresolved-symbols
This restores the linker's default behaviour of generating errors when it
is reporting unresolved symbols.
.Pp
.It  --whole-archive
For each archive mentioned on the command line after the
.Op --whole-archive
option, include every object file in the archive in the link, rather than
searching the archive for the required object files. This is normally used
to turn an archive file into a shared library, forcing every object to be
included in the resulting shared library. This option may be used more than
once.
.Pp
Two notes when using this option from gcc: First, gcc doesn't know about this
option, so you have to use
.Op -Wl,-whole-archive .
Second, don't forget to use
.Op -Wl,-no-whole-archive
after your list of archives, because gcc will add its own list of archives
to your link and you may not want this flag to affect those as well.
.Pp
.It  --wrap Va symbol
Use a wrapper function for
.Va symbol .
Any undefined reference to
.Va symbol
will be resolved to
.Li __wrap_ Va symbol .
Any undefined reference to
.Li __real_ Va symbol
will be resolved to
.Va symbol .
.Pp
This can be used to provide a wrapper for a system function. The wrapper function
should be called
.Li __wrap_ Va symbol .
If it wishes to call the system function, it should call
.Li __real_ Va symbol .
.Pp
Here is a trivial example:
.Pp
.Bd -literal -offset indent
void *
__wrap_malloc (size_t c)
{
  printf ("malloc called with %zu\en", c);
  return __real_malloc (c);
}
.Ed
.Pp
If you link other code with this file using
.Op --wrap malloc ,
then all calls to
.Li malloc
will call the function
.Li __wrap_malloc
instead. The call to
.Li __real_malloc
in
.Li __wrap_malloc
will call the real
.Li malloc
function.
.Pp
You may wish to provide a
.Li __real_malloc
function as well, so that links without the
.Op --wrap
option will succeed. If you do this, you should not put the definition of
.Li __real_malloc
in the same file as
.Li __wrap_malloc ;
if you do, the assembler may resolve the call before the linker has a chance
to wrap it to
.Li malloc .
.Pp
.It  --eh-frame-hdr
Request creation of
.Li .eh_frame_hdr
section and ELF
.Li PT_GNU_EH_FRAME
segment header.
.Pp
.It  --enable-new-dtags
.It  --disable-new-dtags
This linker can create the new dynamic tags in ELF. But the older ELF systems
may not understand them. If you specify
.Op --enable-new-dtags ,
the dynamic tags will be created as needed. If you specify
.Op --disable-new-dtags ,
no new dynamic tags will be created. By default, the new dynamic tags are
not created. Note that those options are only available for ELF systems.
.Pp
.It  --hash-size= Va number
Set the default size of the linker's hash tables to a prime number close to
.Va number .
Increasing this value can reduce the length of time it takes the linker to
perform its tasks, at the expense of increasing the linker's memory requirements.
Similarly reducing this value can reduce the memory requirements at the expense
of speed.
.Pp
.It  --hash-style= Va style
Set the type of linker's hash table(s).
.Va style
can be either
.Li sysv
for classic ELF
.Li .hash
section,
.Li GNU
for new style GNU
.Li .GNU.hash
section or
.Li both
for both the classic ELF
.Li .hash
and new style GNU
.Li .GNU.hash
hash tables. The default is
.Li sysv .
.Pp
.It  --reduce-memory-overheads
This option reduces memory requirements at ld runtime, at the expense of linking
speed. This was introduced to select the old O(n^2) algorithm for link map
file generation, rather than the new O(n) algorithm which uses about 40% more
memory for symbol storage.
.Pp
Another effect of the switch is to set the default hash table size to 1021,
which again saves memory at the cost of lengthening the linker's run time.
This is not done however if the
.Op --hash-size
switch has been used.
.Pp
The
.Op --reduce-memory-overheads
switch may be also be used to enable other tradeoffs in future versions of
the linker.
.Pp
.El
.Em  Options Specific to i386 PE Targets
.Pp
The i386 PE linker supports the
.Op -shared
option, which causes the output to be a dynamically linked library (DLL) instead
of a normal executable. You should name the output
.Li *.dll
when you use this option. In addition, the linker fully supports the standard
.Li *.def
files, which may be specified on the linker command line like an object file
(in fact, it should precede archives it exports symbols from, to ensure that
they get linked in, just like a normal object file).
.Pp
In addition to the options common to all targets, the i386 PE linker support
additional command line options that are specific to the i386 PE target. Options
that take values may be separated from their values by either a space or an
equals sign.
.Pp
.Bl -tag -width Ds
.It  --add-stdcall-alias
If given, symbols with a stdcall suffix (@
.Va nn )
will be exported as-is and also with the suffix stripped. [This option is
specific to the i386 PE targeted port of the linker]
.Pp
.It  --base-file Va file
Use
.Va file
as the name of a file in which to save the base addresses of all the relocations
needed for generating DLLs with
.Pa dlltool .
[This is an i386 PE specific option]
.Pp
.It  --dll
Create a DLL instead of a regular executable. You may also use
.Op -shared
or specify a
.Li LIBRARY
in a given
.Li .def
file. [This option is specific to the i386 PE targeted port of the linker]
.Pp
.It  --enable-stdcall-fixup
.It  --disable-stdcall-fixup
If the link finds a symbol that it cannot resolve, it will attempt to do \(lqfuzzy
linking\(rq by looking for another defined symbol that differs only in the format
of the symbol name (cdecl vs stdcall) and will resolve that symbol by linking
to the match. For example, the undefined symbol
.Li _foo
might be linked to the function
.Li _foo@12 ,
or the undefined symbol
.Li _bar@16
might be linked to the function
.Li _bar .
When the linker does this, it prints a warning, since it normally should have
failed to link, but sometimes import libraries generated from third-party
dlls may need this feature to be usable. If you specify
.Op --enable-stdcall-fixup ,
this feature is fully enabled and warnings are not printed. If you specify
.Op --disable-stdcall-fixup ,
this feature is disabled and such mismatches are considered to be errors.
[This option is specific to the i386 PE targeted port of the linker]
.Pp
.It  --export-all-symbols
If given, all global symbols in the objects used to build a DLL will be exported
by the DLL. Note that this is the default if there otherwise wouldn't be any
exported symbols. When symbols are explicitly exported via DEF files or implicitly
exported via function attributes, the default is to not export anything else
unless this option is given. Note that the symbols
.Li DllMain@12 ,
.Li DllEntryPoint@0 ,
.Li DllMainCRTStartup@12 ,
and
.Li impure_ptr
will not be automatically exported. Also, symbols imported from other DLLs
will not be re-exported, nor will symbols specifying the DLL's internal layout
such as those beginning with
.Li _head_
or ending with
.Li _iname .
In addition, no symbols from
.Li libgcc ,
.Li libstd++ ,
.Li libmingw32 ,
or
.Li crtX.o
will be exported. Symbols whose names begin with
.Li __rtti_
or
.Li __builtin_
will not be exported, to help with C++ DLLs. Finally, there is an extensive
list of cygwin-private symbols that are not exported (obviously, this applies
on when building DLLs for cygwin targets). These cygwin-excludes are:
.Li _cygwin_dll_entry@12 ,
.Li _cygwin_crt0_common@8 ,
.Li _cygwin_noncygwin_dll_entry@12 ,
.Li _fmode ,
.Li _impure_ptr ,
.Li cygwin_attach_dll ,
.Li cygwin_premain0 ,
.Li cygwin_premain1 ,
.Li cygwin_premain2 ,
.Li cygwin_premain3 ,
and
.Li environ .
[This option is specific to the i386 PE targeted port of the linker]
.Pp
.It  --exclude-symbols Va symbol, Va symbol,...
Specifies a list of symbols which should not be automatically exported. The
symbol names may be delimited by commas or colons. [This option is specific
to the i386 PE targeted port of the linker]
.Pp
.It  --file-alignment
Specify the file alignment. Sections in the file will always begin at file
offsets which are multiples of this number. This defaults to 512. [This option
is specific to the i386 PE targeted port of the linker]
.Pp
.It  --heap Va reserve
.It  --heap Va reserve, Va commit
Specify the amount of memory to reserve (and optionally commit) to be used
as heap for this program. The default is 1Mb reserved, 4K committed. [This
option is specific to the i386 PE targeted port of the linker]
.Pp
.It  --image-base Va value
Use
.Va value
as the base address of your program or dll. This is the lowest memory location
that will be used when your program or dll is loaded. To reduce the need to
relocate and improve performance of your dlls, each should have a unique base
address and not overlap any other dlls. The default is 0x400000 for executables,
and 0x10000000 for dlls. [This option is specific to the i386 PE targeted
port of the linker]
.Pp
.It  --kill-at
If given, the stdcall suffixes (@
.Va nn )
will be stripped from symbols before they are exported. [This option is specific
to the i386 PE targeted port of the linker]
.Pp
.It  --large-address-aware
If given, the appropriate bit in the \(lqCharacteristics\(rq field of the COFF header
is set to indicate that this executable supports virtual addresses greater
than 2 gigabytes. This should be used in conjunction with the /3GB or /USERVA=
.Va value
megabytes switch in the \(lq[operating systems]\(rq section of the BOOT.INI. Otherwise,
this bit has no effect. [This option is specific to PE targeted ports of the
linker]
.Pp
.It  --major-image-version Va value
Sets the major number of the \(lqimage version\(rq. Defaults to 1. [This option is
specific to the i386 PE targeted port of the linker]
.Pp
.It  --major-os-version Va value
Sets the major number of the \(lqos version\(rq. Defaults to 4. [This option is specific
to the i386 PE targeted port of the linker]
.Pp
.It  --major-subsystem-version Va value
Sets the major number of the \(lqsubsystem version\(rq. Defaults to 4. [This option
is specific to the i386 PE targeted port of the linker]
.Pp
.It  --minor-image-version Va value
Sets the minor number of the \(lqimage version\(rq. Defaults to 0. [This option is
specific to the i386 PE targeted port of the linker]
.Pp
.It  --minor-os-version Va value
Sets the minor number of the \(lqos version\(rq. Defaults to 0. [This option is specific
to the i386 PE targeted port of the linker]
.Pp
.It  --minor-subsystem-version Va value
Sets the minor number of the \(lqsubsystem version\(rq. Defaults to 0. [This option
is specific to the i386 PE targeted port of the linker]
.Pp
.It  --output-def Va file
The linker will create the file
.Va file
which will contain a DEF file corresponding to the DLL the linker is generating.
This DEF file (which should be called
.Li *.def )
may be used to create an import library with
.Li dlltool
or may be used as a reference to automatically or implicitly exported symbols.
[This option is specific to the i386 PE targeted port of the linker]
.Pp
.It  --out-implib Va file
The linker will create the file
.Va file
which will contain an import lib corresponding to the DLL the linker is generating.
This import lib (which should be called
.Li *.dll.a
or
.Li *.a
may be used to link clients against the generated DLL; this behaviour makes
it possible to skip a separate
.Li dlltool
import library creation step. [This option is specific to the i386 PE targeted
port of the linker]
.Pp
.It  --enable-auto-image-base
Automatically choose the image base for DLLs, unless one is specified using
the
.Li --image-base
argument. By using a hash generated from the dllname to create unique image
bases for each DLL, in-memory collisions and relocations which can delay program
execution are avoided. [This option is specific to the i386 PE targeted port
of the linker]
.Pp
.It  --disable-auto-image-base
Do not automatically generate a unique image base. If there is no user-specified
image base (
.Li --image-base )
then use the platform default. [This option is specific to the i386 PE targeted
port of the linker]
.Pp
.It  --dll-search-prefix Va string
When linking dynamically to a dll without an import library, search for
.Li <string><basename>.dll
in preference to
.Li lib<basename>.dll .
This behaviour allows easy distinction between DLLs built for the various
"subplatforms": native, cygwin, uwin, pw, etc. For instance, cygwin DLLs typically
use
.Li --dll-search-prefix=cyg .
[This option is specific to the i386 PE targeted port of the linker]
.Pp
.It  --enable-auto-import
Do sophisticated linking of
.Li _symbol
to
.Li __imp__symbol
for DATA imports from DLLs, and create the necessary thunking symbols when
building the import libraries with those DATA exports. Note: Use of the 'auto-import'
extension will cause the text section of the image file to be made writable.
This does not conform to the PE-COFF format specification published by Microsoft.
.Pp
Using 'auto-import' generally will 'just work' -- but sometimes you may see
this message:
.Pp
"variable '<var>' can't be auto-imported. Please read the documentation for
ld's
.Li --enable-auto-import
for details."
.Pp
This message occurs when some (sub)expression accesses an address ultimately
given by the sum of two constants (Win32 import tables only allow one). Instances
where this may occur include accesses to member fields of struct variables
imported from a DLL, as well as using a constant index into an array variable
imported from a DLL. Any multiword variable (arrays, structs, long long, etc)
may trigger this error condition. However, regardless of the exact data type
of the offending exported variable, ld will always detect it, issue the warning,
and exit.
.Pp
There are several ways to address this difficulty, regardless of the data
type of the exported variable:
.Pp
One way is to use --enable-runtime-pseudo-reloc switch. This leaves the task
of adjusting references in your client code for runtime environment, so this
method works only when runtime environment supports this feature.
.Pp
A second solution is to force one of the 'constants' to be a variable -- that
is, unknown and un-optimizable at compile time. For arrays, there are two
possibilities: a) make the indexee (the array's address) a variable, or b)
make the 'constant' index a variable. Thus:
.Pp
.Bd -literal -offset indent
extern type extern_array[];
extern_array[1] --> 
   { volatile type *t=extern_array; t[1] }
.Ed
.Pp
or
.Pp
.Bd -literal -offset indent
extern type extern_array[];
extern_array[1] --> 
   { volatile int t=1; extern_array[t] }
.Ed
.Pp
For structs (and most other multiword data types) the only option is to make
the struct itself (or the long long, or the ...) variable:
.Pp
.Bd -literal -offset indent
extern struct s extern_struct;
extern_struct.field --> 
   { volatile struct s *t=&extern_struct; t->field }
.Ed
.Pp
or
.Pp
.Bd -literal -offset indent
extern long long extern_ll;
extern_ll -->
  { volatile long long * local_ll=&extern_ll; *local_ll }
.Ed
.Pp
A third method of dealing with this difficulty is to abandon 'auto-import'
for the offending symbol and mark it with
.Li __declspec(dllimport) .
However, in practise that requires using compile-time #defines to indicate
whether you are building a DLL, building client code that will link to the
DLL, or merely building/linking to a static library. In making the choice
between the various methods of resolving the 'direct address with constant
offset' problem, you should consider typical real-world usage:
.Pp
Original:
.Bd -literal -offset indent
--foo.h
extern int arr[];
--foo.c
#include "foo.h"
void main(int argc, char **argv){
  printf("%d\en",arr[1]);
}
.Ed
.Pp
Solution 1:
.Bd -literal -offset indent
--foo.h
extern int arr[];
--foo.c
#include "foo.h"
void main(int argc, char **argv){
  /* This workaround is for win32 and cygwin; do not "optimize" */
  volatile int *parr = arr;
  printf("%d\en",parr[1]);
}
.Ed
.Pp
Solution 2:
.Bd -literal -offset indent
--foo.h
/* Note: auto-export is assumed (no __declspec(dllexport)) */
#if (defined(_WIN32) || defined(__CYGWIN__)) && \e
  !(defined(FOO_BUILD_DLL) || defined(FOO_STATIC))
#define FOO_IMPORT __declspec(dllimport)
#else
#define FOO_IMPORT
#endif
extern FOO_IMPORT int arr[];
--foo.c
#include "foo.h"
void main(int argc, char **argv){
  printf("%d\en",arr[1]);
}
.Ed
.Pp
A fourth way to avoid this problem is to re-code your library to use a functional
interface rather than a data interface for the offending variables (e.g. set_foo()
and get_foo() accessor functions). [This option is specific to the i386 PE
targeted port of the linker]
.Pp
.It  --disable-auto-import
Do not attempt to do sophisticated linking of
.Li _symbol
to
.Li __imp__symbol
for DATA imports from DLLs. [This option is specific to the i386 PE targeted
port of the linker]
.Pp
.It  --enable-runtime-pseudo-reloc
If your code contains expressions described in --enable-auto-import section,
that is, DATA imports from DLL with non-zero offset, this switch will create
a vector of 'runtime pseudo relocations' which can be used by runtime environment
to adjust references to such data in your client code. [This option is specific
to the i386 PE targeted port of the linker]
.Pp
.It  --disable-runtime-pseudo-reloc
Do not create pseudo relocations for non-zero offset DATA imports from DLLs.
This is the default. [This option is specific to the i386 PE targeted port
of the linker]
.Pp
.It  --enable-extra-pe-debug
Show additional debug info related to auto-import symbol thunking. [This option
is specific to the i386 PE targeted port of the linker]
.Pp
.It  --section-alignment
Sets the section alignment. Sections in memory will always begin at addresses
which are a multiple of this number. Defaults to 0x1000. [This option is specific
to the i386 PE targeted port of the linker]
.Pp
.It  --stack Va reserve
.It  --stack Va reserve, Va commit
Specify the amount of memory to reserve (and optionally commit) to be used
as stack for this program. The default is 2Mb reserved, 4K committed. [This
option is specific to the i386 PE targeted port of the linker]
.Pp
.It  --subsystem Va which
.It  --subsystem Va which: Va major
.It  --subsystem Va which: Va major. Va minor
Specifies the subsystem under which your program will execute. The legal values
for
.Va which
are
.Li native ,
.Li windows ,
.Li console ,
.Li posix ,
and
.Li xbox .
You may optionally set the subsystem version also. Numeric values are also
accepted for
.Va which .
[This option is specific to the i386 PE targeted port of the linker]
.Pp
.El
.Em  Options specific to Motorola 68HC11 and 68HC12 targets
.Pp
The 68HC11 and 68HC12 linkers support specific options to control the memory
bank switching mapping and trampoline code generation.
.Pp
.Bl -tag -width Ds
.It  --no-trampoline
This option disables the generation of trampoline. By default a trampoline
is generated for each far function which is called using a
.Li jsr
instruction (this happens when a pointer to a far function is taken).
.Pp
.It  --bank-window Va name
This option indicates to the linker the name of the memory region in the
.Li MEMORY
specification that describes the memory bank window. The definition of such
region is then used by the linker to compute paging and addresses within the
memory window.
.Pp
.El
.Ss  Environment Variables
You can change the behaviour of
.Xr ld
with the environment variables
.Li GNUTARGET ,
.Li LDEMULATION
and
.Li COLLECT_NO_DEMANGLE .
.Pp
.Li GNUTARGET
determines the input-file object format if you don't use
.Li -b
(or its synonym
.Li --format ) .
Its value should be one of the BFD names for an input format (see Section
.Dq BFD ) .
If there is no
.Li GNUTARGET
in the environment,
.Xr ld
uses the natural format of the target. If
.Li GNUTARGET
is set to
.Li default
then BFD attempts to discover the input format by examining binary input files;
this method often succeeds, but there are potential ambiguities, since there
is no method of ensuring that the magic number used to specify object-file
formats is unique. However, the configuration procedure for BFD on each system
places the conventional format for that system first in the search-list, so
ambiguities are resolved in favor of convention.
.Pp
.Li LDEMULATION
determines the default emulation if you don't use the
.Li -m
option. The emulation can affect various aspects of linker behaviour, particularly
the default linker script. You can list the available emulations with the
.Li --verbose
or
.Li -V
options. If the
.Li -m
option is not used, and the
.Li LDEMULATION
environment variable is not defined, the default emulation depends upon how
the linker was configured.
.Pp
Normally, the linker will default to demangling symbols. However, if
.Li COLLECT_NO_DEMANGLE
is set in the environment, then it will default to not demangling symbols.
This environment variable is used in a similar fashion by the
.Li gcc
linker wrapper program. The default may be overridden by the
.Li --demangle
and
.Li --no-demangle
options.
.Pp
.Sh  Linker Scripts
Every link is controlled by a
.Em linker script .
This script is written in the linker command language.
.Pp
The main purpose of the linker script is to describe how the sections in the
input files should be mapped into the output file, and to control the memory
layout of the output file. Most linker scripts do nothing more than this.
However, when necessary, the linker script can also direct the linker to perform
many other operations, using the commands described below.
.Pp
The linker always uses a linker script. If you do not supply one yourself,
the linker will use a default script that is compiled into the linker executable.
You can use the
.Li --verbose
command line option to display the default linker script. Certain command
line options, such as
.Li -r
or
.Li -N ,
will affect the default linker script.
.Pp
You may supply your own linker script by using the
.Li -T
command line option. When you do this, your linker script will replace the
default linker script.
.Pp
You may also use linker scripts implicitly by naming them as input files to
the linker, as though they were files to be linked.See Section
.Dq Implicit Linker Scripts .
.Pp
.Ss  Basic Linker Script Concepts
We need to define some basic concepts and vocabulary in order to describe
the linker script language.
.Pp
The linker combines input files into a single output file. The output file
and each input file are in a special data format known as an
.Em object file format .
Each file is called an
.Em object file .
The output file is often called an
.Em executable ,
but for our purposes we will also call it an object file. Each object file
has, among other things, a list of
.Em sections .
We sometimes refer to a section in an input file as an
.Em input section ;
similarly, a section in the output file is an
.Em output section .
.Pp
Each section in an object file has a name and a size. Most sections also have
an associated block of data, known as the
.Em section contents .
A section may be marked as
.Em loadable ,
which mean that the contents should be loaded into memory when the output
file is run. A section with no contents may be
.Em allocatable ,
which means that an area in memory should be set aside, but nothing in particular
should be loaded there (in some cases this memory must be zeroed out). A section
which is neither loadable nor allocatable typically contains some sort of
debugging information.
.Pp
Every loadable or allocatable output section has two addresses. The first
is the
.Em VMA ,
or virtual memory address. This is the address the section will have when
the output file is run. The second is the
.Em LMA ,
or load memory address. This is the address at which the section will be loaded.
In most cases the two addresses will be the same. An example of when they
might be different is when a data section is loaded into ROM, and then copied
into RAM when the program starts up (this technique is often used to initialize
global variables in a ROM based system). In this case the ROM address would
be the LMA, and the RAM address would be the VMA.
.Pp
You can see the sections in an object file by using the
.Li objdump
program with the
.Li -h
option.
.Pp
Every object file also has a list of
.Em symbols ,
known as the
.Em symbol table .
A symbol may be defined or undefined. Each symbol has a name, and each defined
symbol has an address, among other information. If you compile a C or C++
program into an object file, you will get a defined symbol for every defined
function and global or static variable. Every undefined function or global
variable which is referenced in the input file will become an undefined symbol.
.Pp
You can see the symbols in an object file by using the
.Li nm
program, or by using the
.Li objdump
program with the
.Li -t
option.
.Pp
.Ss  Linker Script Format
Linker scripts are text files.
.Pp
You write a linker script as a series of commands. Each command is either
a keyword, possibly followed by arguments, or an assignment to a symbol. You
may separate commands using semicolons. Whitespace is generally ignored.
.Pp
Strings such as file or format names can normally be entered directly. If
the file name contains a character such as a comma which would otherwise serve
to separate file names, you may put the file name in double quotes. There
is no way to use a double quote character in a file name.
.Pp
You may include comments in linker scripts just as in C, delimited by
.Li /*
and
.Li */ .
As in C, comments are syntactically equivalent to whitespace.
.Pp
.Ss  Simple Linker Script Example
Many linker scripts are fairly simple.
.Pp
The simplest possible linker script has just one command:
.Li SECTIONS .
You use the
.Li SECTIONS
command to describe the memory layout of the output file.
.Pp
The
.Li SECTIONS
command is a powerful command. Here we will describe a simple use of it. Let's
assume your program consists only of code, initialized data, and uninitialized
data. These will be in the
.Li .text ,
.Li .data ,
and
.Li .bss
sections, respectively. Let's assume further that these are the only sections
which appear in your input files.
.Pp
For this example, let's say that the code should be loaded at address 0x10000,
and that the data should start at address 0x8000000. Here is a linker script
which will do that:
.Bd -literal -offset indent
SECTIONS
{
  . = 0x10000;
  .text : { *(.text) }
  . = 0x8000000;
  .data : { *(.data) }
  .bss : { *(.bss) }
}
.Ed
.Pp
You write the
.Li SECTIONS
command as the keyword
.Li SECTIONS ,
followed by a series of symbol assignments and output section descriptions
enclosed in curly braces.
.Pp
The first line inside the
.Li SECTIONS
command of the above example sets the value of the special symbol
.Li . ,
which is the location counter. If you do not specify the address of an output
section in some other way (other ways are described later), the address is
set from the current value of the location counter. The location counter is
then incremented by the size of the output section. At the start of the
.Li SECTIONS
command, the location counter has the value
.Li 0 .
.Pp
The second line defines an output section,
.Li .text .
The colon is required syntax which may be ignored for now. Within the curly
braces after the output section name, you list the names of the input sections
which should be placed into this output section. The
.Li *
is a wildcard which matches any file name. The expression
.Li *(.text)
means all
.Li .text
input sections in all input files.
.Pp
Since the location counter is
.Li 0x10000
when the output section
.Li .text
is defined, the linker will set the address of the
.Li .text
section in the output file to be
.Li 0x10000 .
.Pp
The remaining lines define the
.Li .data
and
.Li .bss
sections in the output file. The linker will place the
.Li .data
output section at address
.Li 0x8000000 .
After the linker places the
.Li .data
output section, the value of the location counter will be
.Li 0x8000000
plus the size of the
.Li .data
output section. The effect is that the linker will place the
.Li .bss
output section immediately after the
.Li .data
output section in memory.
.Pp
The linker will ensure that each output section has the required alignment,
by increasing the location counter if necessary. In this example, the specified
addresses for the
.Li .text
and
.Li .data
sections will probably satisfy any alignment constraints, but the linker may
have to create a small gap between the
.Li .data
and
.Li .bss
sections.
.Pp
That's it! That's a simple and complete linker script.
.Pp
.Ss  Simple Linker Script Commands
In this section we describe the simple linker script commands.
.Pp
.Em  Setting the Entry Point
.Pp
The first instruction to execute in a program is called the
.Em entry point .
You can use the
.Li ENTRY
linker script command to set the entry point. The argument is a symbol name:
.Bd -literal -offset indent
ENTRY(symbol)
.Ed
.Pp
There are several ways to set the entry point. The linker will set the entry
point by trying each of the following methods in order, and stopping when
one of them succeeds:
.Bl -bullet
.It
the
.Li -e
.Va entry
command-line option;
.It
the
.Li ENTRY( Va symbol)
command in a linker script;
.It
the value of the symbol
.Li start ,
if defined;
.It
the address of the first byte of the
.Li .text
section, if present;
.It
The address
.Li 0 .
.El
.Pp
.Em  Commands Dealing with Files
.Pp
Several linker script commands deal with files.
.Pp
.Bl -tag -width Ds
.It  INCLUDE Va filename
Include the linker script
.Va filename
at this point. The file will be searched for in the current directory, and
in any directory specified with the
.Op -L
option. You can nest calls to
.Li INCLUDE
up to 10 levels deep.
.Pp
.It  INPUT( Va file, Va file, ...)
.It  INPUT( Va file Va file ...)
The
.Li INPUT
command directs the linker to include the named files in the link, as though
they were named on the command line.
.Pp
For example, if you always want to include
.Pa subr.o
any time you do a link, but you can't be bothered to put it on every link
command line, then you can put
.Li INPUT (subr.o)
in your linker script.
.Pp
In fact, if you like, you can list all of your input files in the linker script,
and then invoke the linker with nothing but a
.Li -T
option.
.Pp
In case a
.Em sysroot prefix
is configured, and the filename starts with the
.Li /
character, and the script being processed was located inside the
.Em sysroot prefix ,
the filename will be looked for in the
.Em sysroot prefix .
Otherwise, the linker will try to open the file in the current directory.
If it is not found, the linker will search through the archive library search
path. See the description of
.Li -L
in Options,,Command Line Options.
.Pp
If you use
.Li INPUT (-l Va file) ,
.Xr ld
will transform the name to
.Li lib Va file.a ,
as with the command line argument
.Li -l .
.Pp
When you use the
.Li INPUT
command in an implicit linker script, the files will be included in the link
at the point at which the linker script file is included. This can affect
archive searching.
.Pp
.It  GROUP( Va file, Va file, ...)
.It  GROUP( Va file Va file ...)
The
.Li GROUP
command is like
.Li INPUT ,
except that the named files should all be archives, and they are searched
repeatedly until no new undefined references are created. See the description
of
.Li -(
in Options,,Command Line Options.
.Pp
.It  AS_NEEDED( Va file, Va file, ...)
.It  AS_NEEDED( Va file Va file ...)
This construct can appear only inside of the
.Li INPUT
or
.Li GROUP
commands, among other filenames. The files listed will be handled as if they
appear directly in the
.Li INPUT
or
.Li GROUP
commands, with the exception of ELF shared libraries, that will be added only
when they are actually needed. This construct essentially enables
.Op --as-needed
option for all the files listed inside of it and restores previous
.Op --as-needed
resp.
.Op --no-as-needed
setting afterwards.
.Pp
.It  OUTPUT( Va filename)
The
.Li OUTPUT
command names the output file. Using
.Li OUTPUT( Va filename)
in the linker script is exactly like using
.Li -o Va filename
on the command line (see Section
.Dq Options ) .
If both are used, the command line option takes precedence.
.Pp
You can use the
.Li OUTPUT
command to define a default name for the output file other than the usual
default of
.Pa a.out .
.Pp
.It  SEARCH_DIR( Va path)
The
.Li SEARCH_DIR
command adds
.Va path
to the list of paths where
.Xr ld
looks for archive libraries. Using
.Li SEARCH_DIR( Va path)
is exactly like using
.Li -L Va path
on the command line (see Section
.Dq Options ) .
If both are used, then the linker will search both paths. Paths specified
using the command line option are searched first.
.Pp
.It  STARTUP( Va filename)
The
.Li STARTUP
command is just like the
.Li INPUT
command, except that
.Va filename
will become the first input file to be linked, as though it were specified
first on the command line. This may be useful when using a system in which
the entry point is always the start of the first file.
.El
.Pp
.Em  Commands Dealing with Object File Formats
.Pp
A couple of linker script commands deal with object file formats.
.Pp
.Bl -tag -width Ds
.It  OUTPUT_FORMAT( Va bfdname)
.It  OUTPUT_FORMAT( Va default, Va big, Va little)
The
.Li OUTPUT_FORMAT
command names the BFD format to use for the output file (see Section
.Dq BFD ) .
Using
.Li OUTPUT_FORMAT( Va bfdname)
is exactly like using
.Li --oformat Va bfdname
on the command line (see Section
.Dq Options ) .
If both are used, the command line option takes precedence.
.Pp
You can use
.Li OUTPUT_FORMAT
with three arguments to use different formats based on the
.Li -EB
and
.Li -EL
command line options. This permits the linker script to set the output format
based on the desired endianness.
.Pp
If neither
.Li -EB
nor
.Li -EL
are used, then the output format will be the first argument,
.Va default .
If
.Li -EB
is used, the output format will be the second argument,
.Va big .
If
.Li -EL
is used, the output format will be the third argument,
.Va little .
.Pp
For example, the default linker script for the MIPS ELF target uses this command:
.Bd -literal -offset indent
OUTPUT_FORMAT(elf32-bigmips, elf32-bigmips, elf32-littlemips)
.Ed
This says that the default format for the output file is
.Li elf32-bigmips ,
but if the user uses the
.Li -EL
command line option, the output file will be created in the
.Li elf32-littlemips
format.
.Pp
.It  TARGET( Va bfdname)
The
.Li TARGET
command names the BFD format to use when reading input files. It affects subsequent
.Li INPUT
and
.Li GROUP
commands. This command is like using
.Li -b Va bfdname
on the command line (see Section
.Dq Options ) .
If the
.Li TARGET
command is used but
.Li OUTPUT_FORMAT
is not, then the last
.Li TARGET
command is also used to set the format for the output file.See Section
.Dq BFD .
.El
.Pp
.Em  Other Linker Script Commands
.Pp
There are a few other linker scripts commands.
.Pp
.Bl -tag -width Ds
.It  ASSERT( Va exp, Va message)
Ensure that
.Va exp
is non-zero. If it is zero, then exit the linker with an error code, and print
.Va message .
.Pp
.It  EXTERN( Va symbol Va symbol ...)
Force
.Va symbol
to be entered in the output file as an undefined symbol. Doing this may, for
example, trigger linking of additional modules from standard libraries. You
may list several
.Va symbol
s for each
.Li EXTERN ,
and you may use
.Li EXTERN
multiple times. This command has the same effect as the
.Li -u
command-line option.
.Pp
.It  FORCE_COMMON_ALLOCATION
This command has the same effect as the
.Li -d
command-line option: to make
.Xr ld
assign space to common symbols even if a relocatable output file is specified
(
.Li -r ) .
.Pp
.It  INHIBIT_COMMON_ALLOCATION
This command has the same effect as the
.Li --no-define-common
command-line option: to make
.Li ld
omit the assignment of addresses to common symbols even for a non-relocatable
output file.
.Pp
.It  NOCROSSREFS( Va section Va section ...)
This command may be used to tell
.Xr ld
to issue an error about any references among certain output sections.
.Pp
In certain types of programs, particularly on embedded systems when using
overlays, when one section is loaded into memory, another section will not
be. Any direct references between the two sections would be errors. For example,
it would be an error if code in one section called a function defined in the
other section.
.Pp
The
.Li NOCROSSREFS
command takes a list of output section names. If
.Xr ld
detects any cross references between the sections, it reports an error and
returns a non-zero exit status. Note that the
.Li NOCROSSREFS
command uses output section names, not input section names.
.Pp
.It  OUTPUT_ARCH( Va bfdarch)
Specify a particular output machine architecture. The argument is one of the
names used by the BFD library (see Section
.Dq BFD ) .
You can see the architecture of an object file by using the
.Li objdump
program with the
.Li -f
option.
.El
.Pp
.Ss  Assigning Values to Symbols
You may assign a value to a symbol in a linker script. This will define the
symbol and place it into the symbol table with a global scope.
.Pp
.Em  Simple Assignments
.Pp
You may assign to a symbol using any of the C assignment operators:
.Pp
.Bl -tag -width Ds
.It  Va symbol = Va expression ;
.It  Va symbol += Va expression ;
.It  Va symbol -= Va expression ;
.It  Va symbol *= Va expression ;
.It  Va symbol /= Va expression ;
.It  Va symbol <<= Va expression ;
.It  Va symbol >>= Va expression ;
.It  Va symbol &= Va expression ;
.It  Va symbol |= Va expression ;
.El
.Pp
The first case will define
.Va symbol
to the value of
.Va expression .
In the other cases,
.Va symbol
must already be defined, and the value will be adjusted accordingly.
.Pp
The special symbol name
.Li .
indicates the location counter. You may only use this within a
.Li SECTIONS
command.See Section
.Dq Location Counter .
.Pp
The semicolon after
.Va expression
is required.
.Pp
Expressions are defined below; see Expressions.
.Pp
You may write symbol assignments as commands in their own right, or as statements
within a
.Li SECTIONS
command, or as part of an output section description in a
.Li SECTIONS
command.
.Pp
The section of the symbol will be set from the section of the expression;
for more information, see Expression Section.
.Pp
Here is an example showing the three different places that symbol assignments
may be used:
.Pp
.Bd -literal -offset indent
floating_point = 0;
SECTIONS
{
  .text :
    {
      *(.text)
      _etext = .;
    }
  _bdata = (. + 3) & ~ 3;
  .data : { *(.data) }
}
.Ed
In this example, the symbol
.Li floating_point
will be defined as zero. The symbol
.Li _etext
will be defined as the address following the last
.Li .text
input section. The symbol
.Li _bdata
will be defined as the address following the
.Li .text
output section aligned upward to a 4 byte boundary.
.Pp
.Em  PROVIDE
.Pp
In some cases, it is desirable for a linker script to define a symbol only
if it is referenced and is not defined by any object included in the link.
For example, traditional linkers defined the symbol
.Li etext .
However, ANSI C requires that the user be able to use
.Li etext
as a function name without encountering an error. The
.Li PROVIDE
keyword may be used to define a symbol, such as
.Li etext ,
only if it is referenced but not defined. The syntax is
.Li PROVIDE( Va symbol = Va expression) .
.Pp
Here is an example of using
.Li PROVIDE
to define
.Li etext :
.Bd -literal -offset indent
SECTIONS
{
  .text :
    {
      *(.text)
      _etext = .;
      PROVIDE(etext = .);
    }
}
.Ed
.Pp
In this example, if the program defines
.Li _etext
(with a leading underscore), the linker will give a multiple definition error.
If, on the other hand, the program defines
.Li etext
(with no leading underscore), the linker will silently use the definition
in the program. If the program references
.Li etext
but does not define it, the linker will use the definition in the linker script.
.Pp
.Em  PROVIDE_HIDDEN
.Pp
Similar to
.Li PROVIDE .
For ELF targeted ports, the symbol will be hidden and won't be exported.
.Pp
.Em  Source Code Reference
.Pp
Accessing a linker script defined variable from source code is not intuitive.
In particular a linker script symbol is not equivalent to a variable declaration
in a high level language, it is instead a symbol that does not have a value.
.Pp
Before going further, it is important to note that compilers often transform
names in the source code into different names when they are stored in the
symbol table. For example, Fortran compilers commonly prepend or append an
underscore, and C++ performs extensive
.Li name mangling .
Therefore there might be a discrepancy between the name of a variable as it
is used in source code and the name of the same variable as it is defined
in a linker script. For example in C a linker script variable might be referred
to as:
.Pp
.Bd -literal -offset indent
  extern int foo;
.Ed
.Pp
But in the linker script it might be defined as:
.Pp
.Bd -literal -offset indent
  _foo = 1000;
.Ed
.Pp
In the remaining examples however it is assumed that no name transformation
has taken place.
.Pp
When a symbol is declared in a high level language such as C, two things happen.
The first is that the compiler reserves enough space in the program's memory
to hold the
.Em value
of the symbol. The second is that the compiler creates an entry in the program's
symbol table which holds the symbol's
.Em address .
ie the symbol table contains the address of the block of memory holding the
symbol's value. So for example the following C declaration, at file scope:
.Pp
.Bd -literal -offset indent
  int foo = 1000;
.Ed
.Pp
creates a entry called
.Li foo
in the symbol table. This entry holds the address of an
.Li int
sized block of memory where the number 1000 is initially stored.
.Pp
When a program references a symbol the compiler generates code that first
accesses the symbol table to find the address of the symbol's memory block
and then code to read the value from that memory block. So:
.Pp
.Bd -literal -offset indent
  foo = 1;
.Ed
.Pp
looks up the symbol
.Li foo
in the symbol table, gets the address associated with this symbol and then
writes the value 1 into that address. Whereas:
.Pp
.Bd -literal -offset indent
  int * a = & foo;
.Ed
.Pp
looks up the symbol
.Li foo
in the symbol table, gets it address and then copies this address into the
block of memory associated with the variable
.Li a .
.Pp
Linker scripts symbol declarations, by contrast, create an entry in the symbol
table but do not assign any memory to them. Thus they are an address without
a value. So for example the linker script definition:
.Pp
.Bd -literal -offset indent
  foo = 1000;
.Ed
.Pp
creates an entry in the symbol table called
.Li foo
which holds the address of memory location 1000, but nothing special is stored
at address 1000. This means that you cannot access the
.Em value
of a linker script defined symbol - it has no value - all you can do is access
the
.Em address
of a linker script defined symbol.
.Pp
Hence when you are using a linker script defined symbol in source code you
should always take the address of the symbol, and never attempt to use its
value. For example suppose you want to copy the contents of a section of memory
called .ROM into a section called .FLASH and the linker script contains these
declarations:
.Pp
.Bd -literal -offset indent

  start_of_ROM   = .ROM;
  end_of_ROM     = .ROM + sizeof (.ROM) - 1;
  start_of_FLASH = .FLASH;

.Ed
.Pp
Then the C source code to perform the copy would be:
.Pp
.Bd -literal -offset indent

  extern char start_of_ROM, end_of_ROM, start_of_FLASH;
  
  memcpy (& start_of_FLASH, & start_of_ROM, & end_of_ROM - & start_of_ROM);

.Ed
.Pp
Note the use of the
.Li &
operators. These are correct.
.Pp
.Ss  SECTIONS Command
The
.Li SECTIONS
command tells the linker how to map input sections into output sections, and
how to place the output sections in memory.
.Pp
The format of the
.Li SECTIONS
command is:
.Bd -literal -offset indent
SECTIONS
{
  sections-command
  sections-command
  ...
}
.Ed
.Pp
Each
.Va sections-command
may of be one of the following:
.Pp
.Bl -bullet
.It
an
.Li ENTRY
command (see Section
.Dq Entry Point )
.It
a symbol assignment (see Section
.Dq Assignments )
.It
an output section description
.It
an overlay description
.El
.Pp
The
.Li ENTRY
command and symbol assignments are permitted inside the
.Li SECTIONS
command for convenience in using the location counter in those commands. This
can also make the linker script easier to understand because you can use those
commands at meaningful points in the layout of the output file.
.Pp
Output section descriptions and overlay descriptions are described below.
.Pp
If you do not use a
.Li SECTIONS
command in your linker script, the linker will place each input section into
an identically named output section in the order that the sections are first
encountered in the input files. If all input sections are present in the first
file, for example, the order of sections in the output file will match the
order in the first input file. The first section will be at address zero.
.Pp
.Em  Output Section Description
.Pp
The full description of an output section looks like this:
.Bd -literal -offset indent

section [address] [(type)] :
  [AT(lma)] [ALIGN(section_align)] [SUBALIGN(subsection_align)]
  {
    output-section-command
    output-section-command
    ...
  } [>region] [AT>lma_region] [:phdr :phdr ...] [=fillexp]

.Ed
.Pp
Most output sections do not use most of the optional section attributes.
.Pp
The whitespace around
.Va section
is required, so that the section name is unambiguous. The colon and the curly
braces are also required. The line breaks and other white space are optional.
.Pp
Each
.Va output-section-command
may be one of the following:
.Pp
.Bl -bullet
.It
a symbol assignment (see Section
.Dq Assignments )
.It
an input section description (see Section
.Dq Input Section )
.It
data values to include directly (see Section
.Dq Output Section Data )
.It
a special output section keyword (see Section
.Dq Output Section Keywords )
.El
.Pp
.Em  Output Section Name
.Pp
The name of the output section is
.Va section .
.Va section
must meet the constraints of your output format. In formats which only support
a limited number of sections, such as
.Li a.out ,
the name must be one of the names supported by the format (
.Li a.out ,
for example, allows only
.Li .text ,
.Li .data
or
.Li .bss ) .
If the output format supports any number of sections, but with numbers and
not names (as is the case for Oasys), the name should be supplied as a quoted
numeric string. A section name may consist of any sequence of characters,
but a name which contains any unusual characters such as commas must be quoted.
.Pp
The output section name
.Li /DISCARD/
is special; Output Section Discarding.
.Pp
.Em  Output Section Address
.Pp
The
.Va address
is an expression for the VMA (the virtual memory address) of the output section.
If you do not provide
.Va address ,
the linker will set it based on
.Va region
if present, or otherwise based on the current value of the location counter.
.Pp
If you provide
.Va address ,
the address of the output section will be set to precisely that. If you provide
neither
.Va address
nor
.Va region ,
then the address of the output section will be set to the current value of
the location counter aligned to the alignment requirements of the output section.
The alignment requirement of the output section is the strictest alignment
of any input section contained within the output section.
.Pp
For example,
.Bd -literal -offset indent
\&.text . : { *(.text) }
.Ed
and
.Bd -literal -offset indent
\&.text : { *(.text) }
.Ed
are subtly different. The first will set the address of the
.Li .text
output section to the current value of the location counter. The second will
set it to the current value of the location counter aligned to the strictest
alignment of a
.Li .text
input section.
.Pp
The
.Va address
may be an arbitrary expression; Expressions. For example, if you want to align
the section on a 0x10 byte boundary, so that the lowest four bits of the section
address are zero, you could do something like this:
.Bd -literal -offset indent
\&.text ALIGN(0x10) : { *(.text) }
.Ed
This works because
.Li ALIGN
returns the current location counter aligned upward to the specified value.
.Pp
Specifying
.Va address
for a section will change the value of the location counter.
.Pp
.Em  Input Section Description
.Pp
The most common output section command is an input section description.
.Pp
The input section description is the most basic linker script operation. You
use output sections to tell the linker how to lay out your program in memory.
You use input section descriptions to tell the linker how to map the input
files into your memory layout.
.Pp
.No  Input Section Basics
.Pp
An input section description consists of a file name optionally followed by
a list of section names in parentheses.
.Pp
The file name and the section name may be wildcard patterns, which we describe
further below (see Section
.Dq Input Section Wildcards ) .
.Pp
The most common input section description is to include all input sections
with a particular name in the output section. For example, to include all
input
.Li .text
sections, you would write:
.Bd -literal -offset indent
*(.text)
.Ed
Here the
.Li *
is a wildcard which matches any file name. To exclude a list of files from
matching the file name wildcard, EXCLUDE_FILE may be used to match all files
except the ones specified in the EXCLUDE_FILE list. For example:
.Bd -literal -offset indent
(*(EXCLUDE_FILE (*crtend.o *otherfile.o) .ctors))
.Ed
will cause all .ctors sections from all files except
.Pa crtend.o
and
.Pa otherfile.o
to be included.
.Pp
There are two ways to include more than one section:
.Bd -literal -offset indent
*(.text .rdata)
*(.text) *(.rdata)
.Ed
The difference between these is the order in which the
.Li .text
and
.Li .rdata
input sections will appear in the output section. In the first example, they
will be intermingled, appearing in the same order as they are found in the
linker input. In the second example, all
.Li .text
input sections will appear first, followed by all
.Li .rdata
input sections.
.Pp
You can specify a file name to include sections from a particular file. You
would do this if one or more of your files contain special data that needs
to be at a particular location in memory. For example:
.Bd -literal -offset indent
data.o(.data)
.Ed
.Pp
If you use a file name without a list of sections, then all sections in the
input file will be included in the output section. This is not commonly done,
but it may by useful on occasion. For example:
.Bd -literal -offset indent
data.o
.Ed
.Pp
When you use a file name which does not contain any wild card characters,
the linker will first see if you also specified the file name on the linker
command line or in an
.Li INPUT
command. If you did not, the linker will attempt to open the file as an input
file, as though it appeared on the command line. Note that this differs from
an
.Li INPUT
command, because the linker will not search for the file in the archive search
path.
.Pp
.No  Input Section Wildcard Patterns
.Pp
In an input section description, either the file name or the section name
or both may be wildcard patterns.
.Pp
The file name of
.Li *
seen in many examples is a simple wildcard pattern for the file name.
.Pp
The wildcard patterns are like those used by the Unix shell.
.Pp
.Bl -tag -width Ds
.It  *
matches any number of characters
.It  ?
matches any single character
.It  [ Va chars]
matches a single instance of any of the
.Va chars ;
the
.Li -
character may be used to specify a range of characters, as in
.Li [a-z]
to match any lower case letter
.It  \e
quotes the following character
.El
.Pp
When a file name is matched with a wildcard, the wildcard characters will
not match a
.Li /
character (used to separate directory names on Unix). A pattern consisting
of a single
.Li *
character is an exception; it will always match any file name, whether it
contains a
.Li /
or not. In a section name, the wildcard characters will match a
.Li /
character.
.Pp
File name wildcard patterns only match files which are explicitly specified
on the command line or in an
.Li INPUT
command. The linker does not search directories to expand wildcards.
.Pp
If a file name matches more than one wildcard pattern, or if a file name appears
explicitly and is also matched by a wildcard pattern, the linker will use
the first match in the linker script. For example, this sequence of input
section descriptions is probably in error, because the
.Pa data.o
rule will not be used:
.Bd -literal -offset indent
\&.data : { *(.data) }
\&.data1 : { data.o(.data) }
.Ed
.Pp
Normally, the linker will place files and sections matched by wildcards in
the order in which they are seen during the link. You can change this by using
the
.Li SORT_BY_NAME
keyword, which appears before a wildcard pattern in parentheses (e.g.,
.Li SORT_BY_NAME(.text*) ) .
When the
.Li SORT_BY_NAME
keyword is used, the linker will sort the files or sections into ascending
order by name before placing them in the output file.
.Pp
.Li SORT_BY_ALIGNMENT
is very similar to
.Li SORT_BY_NAME .
The difference is
.Li SORT_BY_ALIGNMENT
will sort sections into ascending order by alignment before placing them in
the output file.
.Pp
.Li SORT
is an alias for
.Li SORT_BY_NAME .
.Pp
When there are nested section sorting commands in linker script, there can
be at most 1 level of nesting for section sorting commands.
.Pp
.Bl -enum
.It
.Li SORT_BY_NAME
(
.Li SORT_BY_ALIGNMENT
(wildcard section pattern)). It will sort the input sections by name first,
then by alignment if 2 sections have the same name.
.It
.Li SORT_BY_ALIGNMENT
(
.Li SORT_BY_NAME
(wildcard section pattern)). It will sort the input sections by alignment
first, then by name if 2 sections have the same alignment.
.It
.Li SORT_BY_NAME
(
.Li SORT_BY_NAME
(wildcard section pattern)) is treated the same as
.Li SORT_BY_NAME
(wildcard section pattern).
.It
.Li SORT_BY_ALIGNMENT
(
.Li SORT_BY_ALIGNMENT
(wildcard section pattern)) is treated the same as
.Li SORT_BY_ALIGNMENT
(wildcard section pattern).
.It
All other nested section sorting commands are invalid.
.El
.Pp
When both command line section sorting option and linker script section sorting
command are used, section sorting command always takes precedence over the
command line option.
.Pp
If the section sorting command in linker script isn't nested, the command
line option will make the section sorting command to be treated as nested
sorting command.
.Pp
.Bl -enum
.It
.Li SORT_BY_NAME
(wildcard section pattern ) with
.Op --sort-sections alignment
is equivalent to
.Li SORT_BY_NAME
(
.Li SORT_BY_ALIGNMENT
(wildcard section pattern)).
.It
.Li SORT_BY_ALIGNMENT
(wildcard section pattern) with
.Op --sort-section name
is equivalent to
.Li SORT_BY_ALIGNMENT
(
.Li SORT_BY_NAME
(wildcard section pattern)).
.El
.Pp
If the section sorting command in linker script is nested, the command line
option will be ignored.
.Pp
If you ever get confused about where input sections are going, use the
.Li -M
linker option to generate a map file. The map file shows precisely how input
sections are mapped to output sections.
.Pp
This example shows how wildcard patterns might be used to partition files.
This linker script directs the linker to place all
.Li .text
sections in
.Li .text
and all
.Li .bss
sections in
.Li .bss .
The linker will place the
.Li .data
section from all files beginning with an upper case character in
.Li .DATA ;
for all other files, the linker will place the
.Li .data
section in
.Li .data .
.Bd -literal -offset indent

SECTIONS {
  .text : { *(.text) }
  .DATA : { [A-Z]*(.data) }
  .data : { *(.data) }
  .bss : { *(.bss) }
}

.Ed
.Pp
.No  Input Section for Common Symbols
.Pp
A special notation is needed for common symbols, because in many object file
formats common symbols do not have a particular input section. The linker
treats common symbols as though they are in an input section named
.Li COMMON .
.Pp
You may use file names with the
.Li COMMON
section just as with any other input sections. You can use this to place common
symbols from a particular input file in one section while common symbols from
other input files are placed in another section.
.Pp
In most cases, common symbols in input files will be placed in the
.Li .bss
section in the output file. For example:
.Bd -literal -offset indent
\&.bss { *(.bss) *(COMMON) }
.Ed
.Pp
Some object file formats have more than one type of common symbol. For example,
the MIPS ELF object file format distinguishes standard common symbols and
small common symbols. In this case, the linker will use a different special
section name for other types of common symbols. In the case of MIPS ELF, the
linker uses
.Li COMMON
for standard common symbols and
.Li .scommon
for small common symbols. This permits you to map the different types of common
symbols into memory at different locations.
.Pp
You will sometimes see
.Li [COMMON]
in old linker scripts. This notation is now considered obsolete. It is equivalent
to
.Li *(COMMON) .
.Pp
.No  Input Section and Garbage Collection
.Pp
When link-time garbage collection is in use (
.Li --gc-sections ) ,
it is often useful to mark sections that should not be eliminated. This is
accomplished by surrounding an input section's wildcard entry with
.Li KEEP() ,
as in
.Li KEEP(*(.init))
or
.Li KEEP(SORT_BY_NAME(*)(.ctors)) .
.Pp
.No  Input Section Example
.Pp
The following example is a complete linker script. It tells the linker to
read all of the sections from file
.Pa all.o
and place them at the start of output section
.Li outputa
which starts at location
.Li 0x10000 .
All of section
.Li .input1
from file
.Pa foo.o
follows immediately, in the same output section. All of section
.Li .input2
from
.Pa foo.o
goes into output section
.Li outputb ,
followed by section
.Li .input1
from
.Pa foo1.o .
All of the remaining
.Li .input1
and
.Li .input2
sections from any files are written to output section
.Li outputc .
.Pp
.Bd -literal -offset indent

SECTIONS {
  outputa 0x10000 :
    {
    all.o
    foo.o (.input1)
    }


  outputb :
    {
    foo.o (.input2)
    foo1.o (.input1)
    }


  outputc :
    {
    *(.input1)
    *(.input2)
    }
}

.Ed
.Pp
.Em  Output Section Data
.Pp
You can include explicit bytes of data in an output section by using
.Li BYTE ,
.Li SHORT ,
.Li LONG ,
.Li QUAD ,
or
.Li SQUAD
as an output section command. Each keyword is followed by an expression in
parentheses providing the value to store (see Section
.Dq Expressions ) .
The value of the expression is stored at the current value of the location
counter.
.Pp
The
.Li BYTE ,
.Li SHORT ,
.Li LONG ,
and
.Li QUAD
commands store one, two, four, and eight bytes (respectively). After storing
the bytes, the location counter is incremented by the number of bytes stored.
.Pp
For example, this will store the byte 1 followed by the four byte value of
the symbol
.Li addr :
.Bd -literal -offset indent
BYTE(1)
LONG(addr)
.Ed
.Pp
When using a 64 bit host or target,
.Li QUAD
and
.Li SQUAD
are the same; they both store an 8 byte, or 64 bit, value. When both host
and target are 32 bits, an expression is computed as 32 bits. In this case
.Li QUAD
stores a 32 bit value zero extended to 64 bits, and
.Li SQUAD
stores a 32 bit value sign extended to 64 bits.
.Pp
If the object file format of the output file has an explicit endianness, which
is the normal case, the value will be stored in that endianness. When the
object file format does not have an explicit endianness, as is true of, for
example, S-records, the value will be stored in the endianness of the first
input object file.
.Pp
Note---these commands only work inside a section description and not between
them, so the following will produce an error from the linker:
.Bd -literal -offset indent
SECTIONS { .text : { *(.text) } LONG(1) .data : { *(.data) } } 
.Ed
whereas this will work:
.Bd -literal -offset indent
SECTIONS { .text : { *(.text) ; LONG(1) } .data : { *(.data) } } 
.Ed
.Pp
You may use the
.Li FILL
command to set the fill pattern for the current section. It is followed by
an expression in parentheses. Any otherwise unspecified regions of memory
within the section (for example, gaps left due to the required alignment of
input sections) are filled with the value of the expression, repeated as necessary.
A
.Li FILL
statement covers memory locations after the point at which it occurs in the
section definition; by including more than one
.Li FILL
statement, you can have different fill patterns in different parts of an output
section.
.Pp
This example shows how to fill unspecified regions of memory with the value
.Li 0x90 :
.Bd -literal -offset indent
FILL(0x90909090)
.Ed
.Pp
The
.Li FILL
command is similar to the
.Li = Va fillexp
output section attribute, but it only affects the part of the section following
the
.Li FILL
command, rather than the entire section. If both are used, the
.Li FILL
command takes precedence.See Section
.Dq Output Section Fill ,
for details on the fill expression.
.Pp
.Em  Output Section Keywords
.Pp
There are a couple of keywords which can appear as output section commands.
.Pp
.Bl -tag -width Ds
.It  CREATE_OBJECT_SYMBOLS
The command tells the linker to create a symbol for each input file. The name
of each symbol will be the name of the corresponding input file. The section
of each symbol will be the output section in which the
.Li CREATE_OBJECT_SYMBOLS
command appears.
.Pp
This is conventional for the a.out object file format. It is not normally
used for any other object file format.
.Pp
.It  CONSTRUCTORS
When linking using the a.out object file format, the linker uses an unusual
set construct to support C++ global constructors and destructors. When linking
object file formats which do not support arbitrary sections, such as ECOFF
and XCOFF, the linker will automatically recognize C++ global constructors
and destructors by name. For these object file formats, the
.Li CONSTRUCTORS
command tells the linker to place constructor information in the output section
where the
.Li CONSTRUCTORS
command appears. The
.Li CONSTRUCTORS
command is ignored for other object file formats.
.Pp
The symbol
.Li __CTOR_LIST__
marks the start of the global constructors, and the symbol
.Li __CTOR_END__
marks the end. Similarly,
.Li __DTOR_LIST__
and
.Li __DTOR_END__
mark the start and end of the global destructors. The first word in the list
is the number of entries, followed by the address of each constructor or destructor,
followed by a zero word. The compiler must arrange to actually run the code.
For these object file formats GNU C++ normally calls constructors from a subroutine
.Li __main ;
a call to
.Li __main
is automatically inserted into the startup code for
.Li main .
GNU C++ normally runs destructors either by using
.Li atexit ,
or directly from the function
.Li exit .
.Pp
For object file formats such as
.Li COFF
or
.Li ELF
which support arbitrary section names, GNU C++ will normally arrange to put
the addresses of global constructors and destructors into the
.Li .ctors
and
.Li .dtors
sections. Placing the following sequence into your linker script will build
the sort of table which the GNU C++ runtime code expects to see.
.Pp
.Bd -literal -offset indent
      __CTOR_LIST__ = .;
      LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
      *(.ctors)
      LONG(0)
      __CTOR_END__ = .;
      __DTOR_LIST__ = .;
      LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
      *(.dtors)
      LONG(0)
      __DTOR_END__ = .;
.Ed
.Pp
If you are using the GNU C++ support for initialization priority, which provides
some control over the order in which global constructors are run, you must
sort the constructors at link time to ensure that they are executed in the
correct order. When using the
.Li CONSTRUCTORS
command, use
.Li SORT_BY_NAME(CONSTRUCTORS)
instead. When using the
.Li .ctors
and
.Li .dtors
sections, use
.Li *(SORT_BY_NAME(.ctors))
and
.Li *(SORT_BY_NAME(.dtors))
instead of just
.Li *(.ctors)
and
.Li *(.dtors) .
.Pp
Normally the compiler and linker will handle these issues automatically, and
you will not need to concern yourself with them. However, you may need to
consider this if you are using C++ and writing your own linker scripts.
.Pp
.El
.Em  Output Section Discarding
.Pp
The linker will not create output sections with no contents. This is for convenience
when referring to input sections that may or may not be present in any of
the input files. For example:
.Bd -literal -offset indent
\&.foo : { *(.foo) }
.Ed
will only create a
.Li .foo
section in the output file if there is a
.Li .foo
section in at least one input file, and if the input sections are not all
empty. Other link script directives that allocate space in an output section
will also create the output section.
.Pp
The linker will ignore address assignments (see Section
.Dq Output Section Address )
on discarded output sections, except when the linker script defines symbols
in the output section. In that case the linker will obey the address assignments,
possibly advancing dot even though the section is discarded.
.Pp
The special output section name
.Li /DISCARD/
may be used to discard input sections. Any input sections which are assigned
to an output section named
.Li /DISCARD/
are not included in the output file.
.Pp
.Em  Output Section Attributes
.Pp
We showed above that the full description of an output section looked like
this:
.Bd -literal -offset indent

section [address] [(type)] :
  [AT(lma)] [ALIGN(section_align)] [SUBALIGN(subsection_align)]
  {
    output-section-command
    output-section-command
    ...
  } [>region] [AT>lma_region] [:phdr :phdr ...] [=fillexp]

.Ed
We've already described
.Va section ,
.Va address ,
and
.Va output-section-command .
In this section we will describe the remaining section attributes.
.Pp
.No  Output Section Type
.Pp
Each output section may have a type. The type is a keyword in parentheses.
The following types are defined:
.Pp
.Bl -tag -width Ds
.It  NOLOAD
The section should be marked as not loadable, so that it will not be loaded
into memory when the program is run.
.It  DSECT
.It  COPY
.It  INFO
.It  OVERLAY
These type names are supported for backward compatibility, and are rarely
used. They all have the same effect: the section should be marked as not allocatable,
so that no memory is allocated for the section when the program is run.
.El
.Pp
The linker normally sets the attributes of an output section based on the
input sections which map into it. You can override this by using the section
type. For example, in the script sample below, the
.Li ROM
section is addressed at memory location
.Li 0
and does not need to be loaded when the program is run. The contents of the
.Li ROM
section will appear in the linker output file as usual.
.Bd -literal -offset indent

SECTIONS {
  ROM 0 (NOLOAD) : { ... }
  ...
}

.Ed
.Pp
.No  Output Section LMA
.Pp
Every section has a virtual address (VMA) and a load address (LMA); see Basic
Script Concepts. The address expression which may appear in an output section
description sets the VMA (see Section
.Dq Output Section Address ) .
.Pp
The expression
.Va lma
that follows the
.Li AT
keyword specifies the load address of the section.
.Pp
Alternatively, with
.Li AT> Va lma_region
expression, you may specify a memory region for the section's load address.See Section
.Dq MEMORY .
Note that if the section has not had a VMA assigned to it then the linker
will use the
.Va lma_region
as the VMA region as well.
.Pp
If neither
.Li AT
nor
.Li AT>
is specified for an allocatable section, the linker will set the LMA such
that the difference between VMA and LMA for the section is the same as the
preceding output section in the same region. If there is no preceding output
section or the section is not allocatable, the linker will set the LMA equal
to the VMA.See Section
.Dq Output Section Region .
.Pp
This feature is designed to make it easy to build a ROM image. For example,
the following linker script creates three output sections: one called
.Li .text ,
which starts at
.Li 0x1000 ,
one called
.Li .mdata ,
which is loaded at the end of the
.Li .text
section even though its VMA is
.Li 0x2000 ,
and one called
.Li .bss
to hold uninitialized data at address
.Li 0x3000 .
The symbol
.Li _data
is defined with the value
.Li 0x2000 ,
which shows that the location counter holds the VMA value, not the LMA value.
.Pp
.Bd -literal -offset indent

SECTIONS
  {
  .text 0x1000 : { *(.text) _etext = . ; }
  .mdata 0x2000 :
    AT ( ADDR (.text) + SIZEOF (.text) )
    { _data = . ; *(.data); _edata = . ;  }
  .bss 0x3000 :
    { _bstart = . ;  *(.bss) *(COMMON) ; _bend = . ;}
}

.Ed
.Pp
The run-time initialization code for use with a program generated with this
linker script would include something like the following, to copy the initialized
data from the ROM image to its runtime address. Notice how this code takes
advantage of the symbols defined by the linker script.
.Pp
.Bd -literal -offset indent

extern char _etext, _data, _edata, _bstart, _bend;
char *src = &_etext;
char *dst = &_data;

/* ROM has data at end of text; copy it. */
while (dst < &_edata) {
  *dst++ = *src++;
}

/* Zero bss */
for (dst = &_bstart; dst< &_bend; dst++)
  *dst = 0;

.Ed
.Pp
.No  Forced Output Alignment
.Pp
You can increase an output section's alignment by using ALIGN.
.Pp
.No  Forced Input Alignment
.Pp
You can force input section alignment within an output section by using SUBALIGN.
The value specified overrides any alignment given by input sections, whether
larger or smaller.
.Pp
.No  Output Section Region
.Pp
You can assign a section to a previously defined region of memory by using
.Li > Va region .
See Section.Dq MEMORY .
.Pp
Here is a simple example:
.Bd -literal -offset indent

MEMORY { rom : ORIGIN = 0x1000, LENGTH = 0x1000 }
SECTIONS { ROM : { *(.text) } >rom }

.Ed
.Pp
.No  Output Section Phdr
.Pp
You can assign a section to a previously defined program segment by using
.Li : Va phdr .
See Section.Dq PHDRS .
If a section is assigned to one or more segments, then all subsequent allocated
sections will be assigned to those segments as well, unless they use an explicitly
.Li : Va phdr
modifier. You can use
.Li :NONE
to tell the linker to not put the section in any segment at all.
.Pp
Here is a simple example:
.Bd -literal -offset indent

PHDRS { text PT_LOAD ; }
SECTIONS { .text : { *(.text) } :text }

.Ed
.Pp
.No  Output Section Fill
.Pp
You can set the fill pattern for an entire section by using
.Li = Va fillexp .
.Va fillexp
is an expression (see Section
.Dq Expressions ) .
Any otherwise unspecified regions of memory within the output section (for
example, gaps left due to the required alignment of input sections) will be
filled with the value, repeated as necessary. If the fill expression is a
simple hex number, ie. a string of hex digit starting with
.Li 0x
and without a trailing
.Li k
or
.Li M ,
then an arbitrarily long sequence of hex digits can be used to specify the
fill pattern; Leading zeros become part of the pattern too. For all other
cases, including extra parentheses or a unary
.Li + ,
the fill pattern is the four least significant bytes of the value of the expression.
In all cases, the number is big-endian.
.Pp
You can also change the fill value with a
.Li FILL
command in the output section commands; (see Section
.Dq Output Section Data ) .
.Pp
Here is a simple example:
.Bd -literal -offset indent

SECTIONS { .text : { *(.text) } =0x90909090 }

.Ed
.Pp
.Em  Overlay Description
.Pp
An overlay description provides an easy way to describe sections which are
to be loaded as part of a single memory image but are to be run at the same
memory address. At run time, some sort of overlay manager will copy the overlaid
sections in and out of the runtime memory address as required, perhaps by
simply manipulating addressing bits. This approach can be useful, for example,
when a certain region of memory is faster than another.
.Pp
Overlays are described using the
.Li OVERLAY
command. The
.Li OVERLAY
command is used within a
.Li SECTIONS
command, like an output section description. The full syntax of the
.Li OVERLAY
command is as follows:
.Bd -literal -offset indent

OVERLAY [start] : [NOCROSSREFS] [AT ( ldaddr )]
  {
    secname1
      {
        output-section-command
        output-section-command
        ...
      } [:phdr...] [=fill]
    secname2
      {
        output-section-command
        output-section-command
        ...
      } [:phdr...] [=fill]
    ...
  } [>region] [:phdr...] [=fill]

.Ed
.Pp
Everything is optional except
.Li OVERLAY
(a keyword), and each section must have a name (
.Va secname1
and
.Va secname2
above). The section definitions within the
.Li OVERLAY
construct are identical to those within the general
.Li SECTIONS
contruct (see Section
.Dq SECTIONS ) ,
except that no addresses and no memory regions may be defined for sections
within an
.Li OVERLAY .
.Pp
The sections are all defined with the same starting address. The load addresses
of the sections are arranged such that they are consecutive in memory starting
at the load address used for the
.Li OVERLAY
as a whole (as with normal section definitions, the load address is optional,
and defaults to the start address; the start address is also optional, and
defaults to the current value of the location counter).
.Pp
If the
.Li NOCROSSREFS
keyword is used, and there any references among the sections, the linker will
report an error. Since the sections all run at the same address, it normally
does not make sense for one section to refer directly to another.See Section
.Dq Miscellaneous Commands .
.Pp
For each section within the
.Li OVERLAY ,
the linker automatically provides two symbols. The symbol
.Li __load_start_ Va secname
is defined as the starting load address of the section. The symbol
.Li __load_stop_ Va secname
is defined as the final load address of the section. Any characters within
.Va secname
which are not legal within C identifiers are removed. C (or assembler) code
may use these symbols to move the overlaid sections around as necessary.
.Pp
At the end of the overlay, the value of the location counter is set to the
start address of the overlay plus the size of the largest section.
.Pp
Here is an example. Remember that this would appear inside a
.Li SECTIONS
construct.
.Bd -literal -offset indent

  OVERLAY 0x1000 : AT (0x4000)
   {
     .text0 { o1/*.o(.text) }
     .text1 { o2/*.o(.text) }
   }

.Ed
This will define both
.Li .text0
and
.Li .text1
to start at address 0x1000.
.Li .text0
will be loaded at address 0x4000, and
.Li .text1
will be loaded immediately after
.Li .text0 .
The following symbols will be defined if referenced:
.Li __load_start_text0 ,
.Li __load_stop_text0 ,
.Li __load_start_text1 ,
.Li __load_stop_text1 .
.Pp
C code to copy overlay
.Li .text1
into the overlay area might look like the following.
.Pp
.Bd -literal -offset indent

  extern char __load_start_text1, __load_stop_text1;
  memcpy ((char *) 0x1000, &__load_start_text1,
          &__load_stop_text1 - &__load_start_text1);

.Ed
.Pp
Note that the
.Li OVERLAY
command is just syntactic sugar, since everything it does can be done using
the more basic commands. The above example could have been written identically
as follows.
.Pp
.Bd -literal -offset indent

  .text0 0x1000 : AT (0x4000) { o1/*.o(.text) }
  PROVIDE (__load_start_text0 = LOADADDR (.text0));
  PROVIDE (__load_stop_text0 = LOADADDR (.text0) + SIZEOF (.text0));
  .text1 0x1000 : AT (0x4000 + SIZEOF (.text0)) { o2/*.o(.text) }
  PROVIDE (__load_start_text1 = LOADADDR (.text1));
  PROVIDE (__load_stop_text1 = LOADADDR (.text1) + SIZEOF (.text1));
  . = 0x1000 + MAX (SIZEOF (.text0), SIZEOF (.text1));

.Ed
.Pp
.Ss  MEMORY Command
The linker's default configuration permits allocation of all available memory.
You can override this by using the
.Li MEMORY
command.
.Pp
The
.Li MEMORY
command describes the location and size of blocks of memory in the target.
You can use it to describe which memory regions may be used by the linker,
and which memory regions it must avoid. You can then assign sections to particular
memory regions. The linker will set section addresses based on the memory
regions, and will warn about regions that become too full. The linker will
not shuffle sections around to fit into the available regions.
.Pp
A linker script may contain at most one use of the
.Li MEMORY
command. However, you can define as many blocks of memory within it as you
wish. The syntax is:
.Bd -literal -offset indent

MEMORY
  {
    name [(attr)] : ORIGIN = origin, LENGTH = len
    ...
  }

.Ed
.Pp
The
.Va name
is a name used in the linker script to refer to the region. The region name
has no meaning outside of the linker script. Region names are stored in a
separate name space, and will not conflict with symbol names, file names,
or section names. Each memory region must have a distinct name.
.Pp
The
.Va attr
string is an optional list of attributes that specify whether to use a particular
memory region for an input section which is not explicitly mapped in the linker
script. As described in SECTIONS, if you do not specify an output section
for some input section, the linker will create an output section with the
same name as the input section. If you define region attributes, the linker
will use them to select the memory region for the output section that it creates.
.Pp
The
.Va attr
string must consist only of the following characters:
.Bl -tag -width Ds
.It  R
Read-only section
.It  W
Read/write section
.It  X
Executable section
.It  A
Allocatable section
.It  I
Initialized section
.It  L
Same as
.Li I
.It  !
Invert the sense of any of the preceding attributes
.El
.Pp
If a unmapped section matches any of the listed attributes other than
.Li ! ,
it will be placed in the memory region. The
.Li !
attribute reverses this test, so that an unmapped section will be placed in
the memory region only if it does not match any of the listed attributes.
.Pp
The
.Va origin
is an numerical expression for the start address of the memory region. The
expression must evaluate to a constant and it cannot involve any symbols.
The keyword
.Li ORIGIN
may be abbreviated to
.Li org
or
.Li o
(but not, for example,
.Li ORG ) .
.Pp
The
.Va len
is an expression for the size in bytes of the memory region. As with the
.Va origin
expression, the expression must be numerical only and must evaluate to a constant.
The keyword
.Li LENGTH
may be abbreviated to
.Li len
or
.Li l .
.Pp
In the following example, we specify that there are two memory regions available
for allocation: one starting at
.Li 0
for 256 kilobytes, and the other starting at
.Li 0x40000000
for four megabytes. The linker will place into the
.Li rom
memory region every section which is not explicitly mapped into a memory region,
and is either read-only or executable. The linker will place other sections
which are not explicitly mapped into a memory region into the
.Li ram
memory region.
.Pp
.Bd -literal -offset indent

MEMORY
  {
    rom (rx)  : ORIGIN = 0, LENGTH = 256K
    ram (!rx) : org = 0x40000000, l = 4M
  }

.Ed
.Pp
Once you define a memory region, you can direct the linker to place specific
output sections into that memory region by using the
.Li > Va region
output section attribute. For example, if you have a memory region named
.Li mem ,
you would use
.Li >mem
in the output section definition.See Section
.Dq Output Section Region .
If no address was specified for the output section, the linker will set the
address to the next available address within the memory region. If the combined
output sections directed to a memory region are too large for the region,
the linker will issue an error message.
.Pp
It is possible to access the origin and length of a memory in an expression
via the
.Li ORIGIN( Va memory)
and
.Li LENGTH( Va memory)
functions:
.Pp
.Bd -literal -offset indent

  _fstack = ORIGIN(ram) + LENGTH(ram) - 4;  

.Ed
.Pp
.Ss  PHDRS Command
The ELF object file format uses
.Em program headers ,
also knows as
.Em segments .
The program headers describe how the program should be loaded into memory.
You can print them out by using the
.Li objdump
program with the
.Li -p
option.
.Pp
When you run an ELF program on a native ELF system, the system loader reads
the program headers in order to figure out how to load the program. This will
only work if the program headers are set correctly. This manual does not describe
the details of how the system loader interprets program headers; for more
information, see the ELF ABI.
.Pp
The linker will create reasonable program headers by default. However, in
some cases, you may need to specify the program headers more precisely. You
may use the
.Li PHDRS
command for this purpose. When the linker sees the
.Li PHDRS
command in the linker script, it will not create any program headers other
than the ones specified.
.Pp
The linker only pays attention to the
.Li PHDRS
command when generating an ELF output file. In other cases, the linker will
simply ignore
.Li PHDRS .
.Pp
This is the syntax of the
.Li PHDRS
command. The words
.Li PHDRS ,
.Li FILEHDR ,
.Li AT ,
and
.Li FLAGS
are keywords.
.Pp
.Bd -literal -offset indent

PHDRS
{
  name type [ FILEHDR ] [ PHDRS ] [ AT ( address ) ]
        [ FLAGS ( flags ) ] ;
}

.Ed
.Pp
The
.Va name
is used only for reference in the
.Li SECTIONS
command of the linker script. It is not put into the output file. Program
header names are stored in a separate name space, and will not conflict with
symbol names, file names, or section names. Each program header must have
a distinct name.
.Pp
Certain program header types describe segments of memory which the system
loader will load from the file. In the linker script, you specify the contents
of these segments by placing allocatable output sections in the segments.
You use the
.Li : Va phdr
output section attribute to place a section in a particular segment.See Section
.Dq Output Section Phdr .
.Pp
It is normal to put certain sections in more than one segment. This merely
implies that one segment of memory contains another. You may repeat
.Li : Va phdr ,
using it once for each segment which should contain the section.
.Pp
If you place a section in one or more segments using
.Li : Va phdr ,
then the linker will place all subsequent allocatable sections which do not
specify
.Li : Va phdr
in the same segments. This is for convenience, since generally a whole set
of contiguous sections will be placed in a single segment. You can use
.Li :NONE
to override the default segment and tell the linker to not put the section
in any segment at all.
.Pp
You may use the
.Li FILEHDR
and
.Li PHDRS
keywords appear after the program header type to further describe the contents
of the segment. The
.Li FILEHDR
keyword means that the segment should include the ELF file header. The
.Li PHDRS
keyword means that the segment should include the ELF program headers themselves.
.Pp
The
.Va type
may be one of the following. The numbers indicate the value of the keyword.
.Pp
.Bl -tag -width Ds
.It  Li PT_NULL (0)
Indicates an unused program header.
.Pp
.It  Li PT_LOAD (1)
Indicates that this program header describes a segment to be loaded from the
file.
.Pp
.It  Li PT_DYNAMIC (2)
Indicates a segment where dynamic linking information can be found.
.Pp
.It  Li PT_INTERP (3)
Indicates a segment where the name of the program interpreter may be found.
.Pp
.It  Li PT_NOTE (4)
Indicates a segment holding note information.
.Pp
.It  Li PT_SHLIB (5)
A reserved program header type, defined but not specified by the ELF ABI.
.Pp
.It  Li PT_PHDR (6)
Indicates a segment where the program headers may be found.
.Pp
.It  Va expression
An expression giving the numeric type of the program header. This may be used
for types not defined above.
.El
.Pp
You can specify that a segment should be loaded at a particular address in
memory by using an
.Li AT
expression. This is identical to the
.Li AT
command used as an output section attribute (see Section
.Dq Output Section LMA ) .
The
.Li AT
command for a program header overrides the output section attribute.
.Pp
The linker will normally set the segment flags based on the sections which
comprise the segment. You may use the
.Li FLAGS
keyword to explicitly specify the segment flags. The value of
.Va flags
must be an integer. It is used to set the
.Li p_flags
field of the program header.
.Pp
Here is an example of
.Li PHDRS .
This shows a typical set of program headers used on a native ELF system.
.Pp
.Bd -literal -offset indent

PHDRS
{
  headers PT_PHDR PHDRS ;
  interp PT_INTERP ;
  text PT_LOAD FILEHDR PHDRS ;
  data PT_LOAD ;
  dynamic PT_DYNAMIC ;
}

SECTIONS
{
  . = SIZEOF_HEADERS;
  .interp : { *(.interp) } :text :interp
  .text : { *(.text) } :text
  .rodata : { *(.rodata) } /* defaults to :text */
  ...
  . = . + 0x1000; /* move to a new page in memory */
  .data : { *(.data) } :data
  .dynamic : { *(.dynamic) } :data :dynamic
  ...
}

.Ed
.Pp
.Ss  VERSION Command
The linker supports symbol versions when using ELF. Symbol versions are only
useful when using shared libraries. The dynamic linker can use symbol versions
to select a specific version of a function when it runs a program that may
have been linked against an earlier version of the shared library.
.Pp
You can include a version script directly in the main linker script, or you
can supply the version script as an implicit linker script. You can also use
the
.Li --version-script
linker option.
.Pp
The syntax of the
.Li VERSION
command is simply
.Bd -literal -offset indent
VERSION { version-script-commands }
.Ed
.Pp
The format of the version script commands is identical to that used by Sun's
linker in Solaris 2.5. The version script defines a tree of version nodes.
You specify the node names and interdependencies in the version script. You
can specify which symbols are bound to which version nodes, and you can reduce
a specified set of symbols to local scope so that they are not globally visible
outside of the shared library.
.Pp
The easiest way to demonstrate the version script language is with a few examples.
.Pp
.Bd -literal -offset indent
VERS_1.1 {
         global:
                 foo1;
         local:
                 old*;
                 original*;
                 new*;
};

VERS_1.2 {
                 foo2;
} VERS_1.1;

VERS_2.0 {
                 bar1; bar2;
         extern "C++" {       
                 ns::*;
                 "int f(int, double)";
         }         
} VERS_1.2;
.Ed
.Pp
This example version script defines three version nodes. The first version
node defined is
.Li VERS_1.1 ;
it has no other dependencies. The script binds the symbol
.Li foo1
to
.Li VERS_1.1 .
It reduces a number of symbols to local scope so that they are not visible
outside of the shared library; this is done using wildcard patterns, so that
any symbol whose name begins with
.Li old ,
.Li original ,
or
.Li new
is matched. The wildcard patterns available are the same as those used in
the shell when matching filenames (also known as \(lqglobbing\(rq). However, if you
specify the symbol name inside double quotes, then the name is treated as
literal, rather than as a glob pattern.
.Pp
Next, the version script defines node
.Li VERS_1.2 .
This node depends upon
.Li VERS_1.1 .
The script binds the symbol
.Li foo2
to the version node
.Li VERS_1.2 .
.Pp
Finally, the version script defines node
.Li VERS_2.0 .
This node depends upon
.Li VERS_1.2 .
The scripts binds the symbols
.Li bar1
and
.Li bar2
are bound to the version node
.Li VERS_2.0 .
.Pp
When the linker finds a symbol defined in a library which is not specifically
bound to a version node, it will effectively bind it to an unspecified base
version of the library. You can bind all otherwise unspecified symbols to
a given version node by using
.Li global: *;
somewhere in the version script.
.Pp
The names of the version nodes have no specific meaning other than what they
might suggest to the person reading them. The
.Li 2.0
version could just as well have appeared in between
.Li 1.1
and
.Li 1.2 .
However, this would be a confusing way to write a version script.
.Pp
Node name can be omitted, provided it is the only version node in the version
script. Such version script doesn't assign any versions to symbols, only selects
which symbols will be globally visible out and which won't.
.Pp
.Bd -literal -offset indent
{ global: foo; bar; local: *; };
.Ed
.Pp
When you link an application against a shared library that has versioned symbols,
the application itself knows which version of each symbol it requires, and
it also knows which version nodes it needs from each shared library it is
linked against. Thus at runtime, the dynamic loader can make a quick check
to make sure that the libraries you have linked against do in fact supply
all of the version nodes that the application will need to resolve all of
the dynamic symbols. In this way it is possible for the dynamic linker to
know with certainty that all external symbols that it needs will be resolvable
without having to search for each symbol reference.
.Pp
The symbol versioning is in effect a much more sophisticated way of doing
minor version checking that SunOS does. The fundamental problem that is being
addressed here is that typically references to external functions are bound
on an as-needed basis, and are not all bound when the application starts up.
If a shared library is out of date, a required interface may be missing; when
the application tries to use that interface, it may suddenly and unexpectedly
fail. With symbol versioning, the user will get a warning when they start
their program if the libraries being used with the application are too old.
.Pp
There are several GNU extensions to Sun's versioning approach. The first of
these is the ability to bind a symbol to a version node in the source file
where the symbol is defined instead of in the versioning script. This was
done mainly to reduce the burden on the library maintainer. You can do this
by putting something like:
.Bd -literal -offset indent
__asm__(".symver original_foo,foo@VERS_1.1");
.Ed
in the C source file. This renames the function
.Li original_foo
to be an alias for
.Li foo
bound to the version node
.Li VERS_1.1 .
The
.Li local:
directive can be used to prevent the symbol
.Li original_foo
from being exported. A
.Li .symver
directive takes precedence over a version script.
.Pp
The second GNU extension is to allow multiple versions of the same function
to appear in a given shared library. In this way you can make an incompatible
change to an interface without increasing the major version number of the
shared library, while still allowing applications linked against the old interface
to continue to function.
.Pp
To do this, you must use multiple
.Li .symver
directives in the source file. Here is an example:
.Pp
.Bd -literal -offset indent
__asm__(".symver original_foo,foo@");
__asm__(".symver old_foo,foo@VERS_1.1");
__asm__(".symver old_foo1,foo@VERS_1.2");
__asm__(".symver new_foo,foo@@VERS_2.0");
.Ed
.Pp
In this example,
.Li foo@
represents the symbol
.Li foo
bound to the unspecified base version of the symbol. The source file that
contains this example would define 4 C functions:
.Li original_foo ,
.Li old_foo ,
.Li old_foo1 ,
and
.Li new_foo .
.Pp
When you have multiple definitions of a given symbol, there needs to be some
way to specify a default version to which external references to this symbol
will be bound. You can do this with the
.Li foo@@VERS_2.0
type of
.Li .symver
directive. You can only declare one version of a symbol as the default in
this manner; otherwise you would effectively have multiple definitions of
the same symbol.
.Pp
If you wish to bind a reference to a specific version of the symbol within
the shared library, you can use the aliases of convenience (i.e.,
.Li old_foo ) ,
or you can use the
.Li .symver
directive to specifically bind to an external version of the function in question.
.Pp
You can also specify the language in the version script:
.Pp
.Bd -literal -offset indent
VERSION extern "lang" { version-script-commands }
.Ed
.Pp
The supported
.Li lang
s are
.Li C ,
.Li C++ ,
and
.Li Java .
The linker will iterate over the list of symbols at the link time and demangle
them according to
.Li lang
before matching them to the patterns specified in
.Li version-script-commands .
.Pp
Demangled names may contains spaces and other special characters. As described
above, you can use a glob pattern to match demangled names, or you can use
a double-quoted string to match the string exactly. In the latter case, be
aware that minor differences (such as differing whitespace) between the version
script and the demangler output will cause a mismatch. As the exact string
generated by the demangler might change in the future, even if the mangled
name does not, you should check that all of your version directives are behaving
as you expect when you upgrade.
.Pp
.Ss  Expressions in Linker Scripts
The syntax for expressions in the linker script language is identical to that
of C expressions. All expressions are evaluated as integers. All expressions
are evaluated in the same size, which is 32 bits if both the host and target
are 32 bits, and is otherwise 64 bits.
.Pp
You can use and set symbol values in expressions.
.Pp
The linker defines several special purpose builtin functions for use in expressions.
.Pp
.Em  Constants
.Pp
All constants are integers.
.Pp
As in C, the linker considers an integer beginning with
.Li 0
to be octal, and an integer beginning with
.Li 0x
or
.Li 0X
to be hexadecimal. The linker considers other integers to be decimal.
.Pp
In addition, you can use the suffixes
.Li K
and
.Li M
to scale a constant by
.Li 1024
or
.Li 1024*1024
respectively. For example, the following all refer to the same quantity:
.Bd -literal -offset indent
_fourk_1 = 4K;
_fourk_2 = 4096;
_fourk_3 = 0x1000;
.Ed
.Pp
.Em  Symbol Names
.Pp
Unless quoted, symbol names start with a letter, underscore, or period and
may include letters, digits, underscores, periods, and hyphens. Unquoted symbol
names must not conflict with any keywords. You can specify a symbol which
contains odd characters or has the same name as a keyword by surrounding the
symbol name in double quotes:
.Bd -literal -offset indent
"SECTION" = 9;
"with a space" = "also with a space" + 10;
.Ed
.Pp
Since symbols can contain many non-alphabetic characters, it is safest to
delimit symbols with spaces. For example,
.Li A-B
is one symbol, whereas
.Li A - B
is an expression involving subtraction.
.Pp
.Em  Orphan Sections
.Pp
Orphan sections are sections present in the input files which are not explicitly
placed into the output file by the linker script. The linker will still copy
these sections into the output file, but it has to guess as to where they
should be placed. The linker uses a simple heuristic to do this. It attempts
to place orphan sections after non-orphan sections of the same attribute,
such as code vs data, loadable vs non-loadable, etc. If there is not enough
room to do this then it places at the end of the file.
.Pp
For ELF targets, the attribute of the section includes section type as well
as section flag.
.Pp
.Em  The Location Counter
.Pp
The special linker variable
.Em dot
.Li .
always contains the current output location counter. Since the
.Li .
always refers to a location in an output section, it may only appear in an
expression within a
.Li SECTIONS
command. The
.Li .
symbol may appear anywhere that an ordinary symbol is allowed in an expression.
.Pp
Assigning a value to
.Li .
will cause the location counter to be moved. This may be used to create holes
in the output section. The location counter may not be moved backwards inside
an output section, and may not be moved backwards outside of an output section
if so doing creates areas with overlapping LMAs.
.Pp
.Bd -literal -offset indent
SECTIONS
{
  output :
    {
      file1(.text)
      . = . + 1000;
      file2(.text)
      . += 1000;
      file3(.text)
    } = 0x12345678;
}
.Ed
In the previous example, the
.Li .text
section from
.Pa file1
is located at the beginning of the output section
.Li output .
It is followed by a 1000 byte gap. Then the
.Li .text
section from
.Pa file2
appears, also with a 1000 byte gap following before the
.Li .text
section from
.Pa file3 .
The notation
.Li = 0x12345678
specifies what data to write in the gaps (see Section
.Dq Output Section Fill ) .
.Pp
Note:
.Li .
actually refers to the byte offset from the start of the current containing
object. Normally this is the
.Li SECTIONS
statement, whose start address is 0, hence
.Li .
can be used as an absolute address. If
.Li .
is used inside a section description however, it refers to the byte offset
from the start of that section, not an absolute address. Thus in a script
like this:
.Pp
.Bd -literal -offset indent
SECTIONS
{
    . = 0x100
    .text: {
      *(.text)
      . = 0x200
    }
    . = 0x500
    .data: {
      *(.data)
      . += 0x600
    }
}
.Ed
.Pp
The
.Li .text
section will be assigned a starting address of 0x100 and a size of exactly
0x200 bytes, even if there is not enough data in the
.Li .text
input sections to fill this area. (If there is too much data, an error will
be produced because this would be an attempt to move
.Li .
backwards). The
.Li .data
section will start at 0x500 and it will have an extra 0x600 bytes worth of
space after the end of the values from the
.Li .data
input sections and before the end of the
.Li .data
output section itself.
.Pp
Setting symbols to the value of the location counter outside of an output
section statement can result in unexpected values if the linker needs to place
orphan sections. For example, given the following:
.Pp
.Bd -literal -offset indent
SECTIONS
{
    start_of_text = . ;
    .text: { *(.text) }
    end_of_text = . ;

    start_of_data = . ;
    .data: { *(.data) }
    end_of_data = . ;
}
.Ed
.Pp
If the linker needs to place some input section, e.g.
.Li .rodata ,
not mentioned in the script, it might choose to place that section between
.Li .text
and
.Li .data .
You might think the linker should place
.Li .rodata
on the blank line in the above script, but blank lines are of no particular
significance to the linker. As well, the linker doesn't associate the above
symbol names with their sections. Instead, it assumes that all assignments
or other statements belong to the previous output section, except for the
special case of an assignment to
.Li . .
I.e., the linker will place the orphan
.Li .rodata
section as if the script was written as follows:
.Pp
.Bd -literal -offset indent
SECTIONS
{
    start_of_text = . ;
    .text: { *(.text) }
    end_of_text = . ;

    start_of_data = . ;
    .rodata: { *(.rodata) }
    .data: { *(.data) }
    end_of_data = . ;
}
.Ed
.Pp
This may or may not be the script author's intention for the value of
.Li start_of_data .
One way to influence the orphan section placement is to assign the location
counter to itself, as the linker assumes that an assignment to
.Li .
is setting the start address of a following output section and thus should
be grouped with that section. So you could write:
.Pp
.Bd -literal -offset indent
SECTIONS
{
    start_of_text = . ;
    .text: { *(.text) }
    end_of_text = . ;

    . = . ;
    start_of_data = . ;
    .data: { *(.data) }
    end_of_data = . ;
}
.Ed
.Pp
Now, the orphan
.Li .rodata
section will be placed between
.Li end_of_text
and
.Li start_of_data .
.Pp
.Em  Operators
.Pp
The linker recognizes the standard C set of arithmetic operators, with the
standard bindings and precedence levels:
.Bd -literal -offset indent
precedence      associativity   Operators                Notes
(highest)
1               left            !  -  ~                  (1)
2               left            *  /  %
3               left            +  -
4               left            >>  <<
5               left            ==  !=  >  <  <=  >=
6               left            &
7               left            |
8               left            &&
9               left            ||
10              right           ? :
11              right           &=  +=  -=  *=  /=       (2)
(lowest)
.Ed
Notes: (1) Prefix operators (2)See Section
.Dq Assignments .
.Pp
.Em  Evaluation
.Pp
The linker evaluates expressions lazily. It only computes the value of an
expression when absolutely necessary.
.Pp
The linker needs some information, such as the value of the start address
of the first section, and the origins and lengths of memory regions, in order
to do any linking at all. These values are computed as soon as possible when
the linker reads in the linker script.
.Pp
However, other values (such as symbol values) are not known or needed until
after storage allocation. Such values are evaluated later, when other information
(such as the sizes of output sections) is available for use in the symbol
assignment expression.
.Pp
The sizes of sections cannot be known until after allocation, so assignments
dependent upon these are not performed until after allocation.
.Pp
Some expressions, such as those depending upon the location counter
.Li . ,
must be evaluated during section allocation.
.Pp
If the result of an expression is required, but the value is not available,
then an error results. For example, a script like the following
.Bd -literal -offset indent

SECTIONS
  {
    .text 9+this_isnt_constant :
      { *(.text) }
  }

.Ed
will cause the error message
.Li non constant expression for initial address .
.Pp
.Em  The Section of an Expression
.Pp
When the linker evaluates an expression, the result is either absolute or
relative to some section. A relative expression is expressed as a fixed offset
from the base of a section.
.Pp
The position of the expression within the linker script determines whether
it is absolute or relative. An expression which appears within an output section
definition is relative to the base of the output section. An expression which
appears elsewhere will be absolute.
.Pp
A symbol set to a relative expression will be relocatable if you request relocatable
output using the
.Li -r
option. That means that a further link operation may change the value of the
symbol. The symbol's section will be the section of the relative expression.
.Pp
A symbol set to an absolute expression will retain the same value through
any further link operation. The symbol will be absolute, and will not have
any particular associated section.
.Pp
You can use the builtin function
.Li ABSOLUTE
to force an expression to be absolute when it would otherwise be relative.
For example, to create an absolute symbol set to the address of the end of
the output section
.Li .data :
.Bd -literal -offset indent
SECTIONS
  {
    .data : { *(.data) _edata = ABSOLUTE(.); }
  }
.Ed
If
.Li ABSOLUTE
were not used,
.Li _edata
would be relative to the
.Li .data
section.
.Pp
.Em  Builtin Functions
.Pp
The linker script language includes a number of builtin functions for use
in linker script expressions.
.Pp
.Bl -tag -width Ds
.It  ABSOLUTE( Va exp)
Return the absolute (non-relocatable, as opposed to non-negative) value of
the expression
.Va exp .
Primarily useful to assign an absolute value to a symbol within a section
definition, where symbol values are normally section relative.See Section
.Dq Expression Section .
.Pp
.It  ADDR( Va section)
Return the absolute address (the VMA) of the named
.Va section .
Your script must previously have defined the location of that section. In
the following example,
.Li symbol_1
and
.Li symbol_2
are assigned identical values:
.Bd -literal -offset indent

SECTIONS { ...
  .output1 :
    {
    start_of_output_1 = ABSOLUTE(.);
    ...
    }
  .output :
    {
    symbol_1 = ADDR(.output1);
    symbol_2 = start_of_output_1;
    }
\&... }

.Ed
.Pp
.It  ALIGN( Va align)
.It  ALIGN( Va exp, Va align)
Return the location counter (
.Li . )
or arbitrary expression aligned to the next
.Va align
boundary. The single operand
.Li ALIGN
doesn't change the value of the location counter---it just does arithmetic
on it. The two operand
.Li ALIGN
allows an arbitrary expression to be aligned upwards (
.Li ALIGN( Va align)
is equivalent to
.Li ALIGN(., Va align) ) .
.Pp
Here is an example which aligns the output
.Li .data
section to the next
.Li 0x2000
byte boundary after the preceding section and sets a variable within the section
to the next
.Li 0x8000
boundary after the input sections:
.Bd -literal -offset indent

SECTIONS { ...
  .data ALIGN(0x2000): {
    *(.data)
    variable = ALIGN(0x8000);
  }
\&... }

.Ed
The first use of
.Li ALIGN
in this example specifies the location of a section because it is used as
the optional
.Va address
attribute of a section definition (see Section
.Dq Output Section Address ) .
The second use of
.Li ALIGN
is used to defines the value of a symbol.
.Pp
The builtin function
.Li NEXT
is closely related to
.Li ALIGN .
.Pp
.It  ALIGNOF( Va section)
Return the alignment in bytes of the named
.Va section ,
if that section has been allocated. If the section has not been allocated
when this is evaluated, the linker will report an error. In the following
example, the alignment of the
.Li .output
section is stored as the first value in that section.
.Bd -literal -offset indent

SECTIONS{ ...
  .output {
    LONG (ALIGNOF (.output))
    ...
    }
\&... }

.Ed
.Pp
.It  BLOCK( Va exp)
This is a synonym for
.Li ALIGN ,
for compatibility with older linker scripts. It is most often seen when setting
the address of an output section.
.Pp
.It  DATA_SEGMENT_ALIGN( Va maxpagesize, Va commonpagesize)
This is equivalent to either
.Bd -literal -offset indent
(ALIGN(maxpagesize) + (. & (maxpagesize - 1)))
.Ed
or
.Bd -literal -offset indent
(ALIGN(maxpagesize) + (. & (maxpagesize - commonpagesize)))
.Ed
depending on whether the latter uses fewer
.Va commonpagesize
sized pages for the data segment (area between the result of this expression
and
.Li DATA_SEGMENT_END )
than the former or not. If the latter form is used, it means
.Va commonpagesize
bytes of runtime memory will be saved at the expense of up to
.Va commonpagesize
wasted bytes in the on-disk file.
.Pp
This expression can only be used directly in
.Li SECTIONS
commands, not in any output section descriptions and only once in the linker
script.
.Va commonpagesize
should be less or equal to
.Va maxpagesize
and should be the system page size the object wants to be optimized for (while
still working on system page sizes up to
.Va maxpagesize ) .
.Pp
Example:
.Bd -literal -offset indent
  . = DATA_SEGMENT_ALIGN(0x10000, 0x2000);
.Ed
.Pp
.It  DATA_SEGMENT_END( Va exp)
This defines the end of data segment for
.Li DATA_SEGMENT_ALIGN
evaluation purposes.
.Pp
.Bd -literal -offset indent
  . = DATA_SEGMENT_END(.);
.Ed
.Pp
.It  DATA_SEGMENT_RELRO_END( Va offset, Va exp)
This defines the end of the
.Li PT_GNU_RELRO
segment when
.Li -z relro
option is used. Second argument is returned. When
.Li -z relro
option is not present,
.Li DATA_SEGMENT_RELRO_END
does nothing, otherwise
.Li DATA_SEGMENT_ALIGN
is padded so that
.Va exp
+
.Va offset
is aligned to the most commonly used page boundary for particular target.
If present in the linker script, it must always come in between
.Li DATA_SEGMENT_ALIGN
and
.Li DATA_SEGMENT_END .
.Pp
.Bd -literal -offset indent
  . = DATA_SEGMENT_RELRO_END(24, .);
.Ed
.Pp
.It  DEFINED( Va symbol)
Return 1 if
.Va symbol
is in the linker global symbol table and is defined before the statement using
DEFINED in the script, otherwise return 0. You can use this function to provide
default values for symbols. For example, the following script fragment shows
how to set a global symbol
.Li begin
to the first location in the
.Li .text
section---but if a symbol called
.Li begin
already existed, its value is preserved:
.Pp
.Bd -literal -offset indent

SECTIONS { ...
  .text : {
    begin = DEFINED(begin) ? begin : . ;
    ...
  }
  ...
}

.Ed
.Pp
.It  LENGTH( Va memory)
Return the length of the memory region named
.Va memory .
.Pp
.It  LOADADDR( Va section)
Return the absolute LMA of the named
.Va section .
This is normally the same as
.Li ADDR ,
but it may be different if the
.Li AT
attribute is used in the output section definition (see Section
.Dq Output Section LMA ) .
.Pp
.It  MAX( Va exp1, Va exp2)
Returns the maximum of
.Va exp1
and
.Va exp2 .
.Pp
.It  MIN( Va exp1, Va exp2)
Returns the minimum of
.Va exp1
and
.Va exp2 .
.Pp
.It  NEXT( Va exp)
Return the next unallocated address that is a multiple of
.Va exp .
This function is closely related to
.Li ALIGN( Va exp) ;
unless you use the
.Li MEMORY
command to define discontinuous memory for the output file, the two functions
are equivalent.
.Pp
.It  ORIGIN( Va memory)
Return the origin of the memory region named
.Va memory .
.Pp
.It  SEGMENT_START( Va segment, Va default)
Return the base address of the named
.Va segment .
If an explicit value has been given for this segment (with a command-line
.Li -T
option) that value will be returned; otherwise the value will be
.Va default .
At present, the
.Li -T
command-line option can only be used to set the base address for the \(lqtext\(rq,
\(lqdata\(rq, and \(lqbss\(rq sections, but you use
.Li SEGMENT_START
with any segment name.
.Pp
.It  SIZEOF( Va section)
Return the size in bytes of the named
.Va section ,
if that section has been allocated. If the section has not been allocated
when this is evaluated, the linker will report an error. In the following
example,
.Li symbol_1
and
.Li symbol_2
are assigned identical values:
.Bd -literal -offset indent

SECTIONS{ ...
  .output {
    .start = . ;
    ...
    .end = . ;
    }
  symbol_1 = .end - .start ;
  symbol_2 = SIZEOF(.output);
\&... }

.Ed
.Pp
.It  SIZEOF_HEADERS
.It  sizeof_headers
Return the size in bytes of the output file's headers. This is information
which appears at the start of the output file. You can use this number when
setting the start address of the first section, if you choose, to facilitate
paging.
.Pp
When producing an ELF output file, if the linker script uses the
.Li SIZEOF_HEADERS
builtin function, the linker must compute the number of program headers before
it has determined all the section addresses and sizes. If the linker later
discovers that it needs additional program headers, it will report an error
.Li not enough room for program headers .
To avoid this error, you must avoid using the
.Li SIZEOF_HEADERS
function, or you must rework your linker script to avoid forcing the linker
to use additional program headers, or you must define the program headers
yourself using the
.Li PHDRS
command (see Section
.Dq PHDRS ) .
.El
.Pp
.Ss  Implicit Linker Scripts
If you specify a linker input file which the linker can not recognize as an
object file or an archive file, it will try to read the file as a linker script.
If the file can not be parsed as a linker script, the linker will report an
error.
.Pp
An implicit linker script will not replace the default linker script.
.Pp
Typically an implicit linker script would contain only symbol assignments,
or the
.Li INPUT ,
.Li GROUP ,
or
.Li VERSION
commands.
.Pp
Any input files read because of an implicit linker script will be read at
the position in the command line where the implicit linker script was read.
This can affect archive searching.
.Pp
.Sh  Machine Dependent Features
.Xr ld
has additional features on some platforms; the following sections describe
them. Machines where
.Xr ld
has no additional functionality are not listed.
.Pp
.Ss  Xr ld and the H8/300
For the H8/300,
.Xr ld
can perform these global optimizations when you specify the
.Li --relax
command-line option.
.Pp
.Bl -tag -width Ds
.It  relaxing address modes
.Xr ld
finds all
.Li jsr
and
.Li jmp
instructions whose targets are within eight bits, and turns them into eight-bit
program-counter relative
.Li bsr
and
.Li bra
instructions, respectively.
.Pp
.It  synthesizing instructions
.Xr ld
finds all
.Li mov.b
instructions which use the sixteen-bit absolute address form, but refer to
the top page of memory, and changes them to use the eight-bit address form.
(That is: the linker turns
.Li mov.b Li @ Va aa:16
into
.Li mov.b Li @ Va aa:8
whenever the address
.Va aa
is in the top page of memory).
.Pp
.It  bit manipulation instructions
.Xr ld
finds all bit manipulation instructions like
.Li band, bclr, biand, bild, bior, bist, bixor, bld, bnot, bor, bset, bst, btst, bxor
which use 32 bit and 16 bit absolute address form, but refer to the top page
of memory, and changes them to use the 8 bit address form. (That is: the linker
turns
.Li bset #xx:3, Li @ Va aa:32
into
.Li bset #xx:3, Li @ Va aa:8
whenever the address
.Va aa
is in the top page of memory).
.Pp
.It  system control instructions
.Xr ld
finds all
.Li ldc.w, stc.w
instructions which use the 32 bit absolute address form, but refer to the
top page of memory, and changes them to use 16 bit address form. (That is:
the linker turns
.Li ldc.w Li @ Va aa:32,ccr
into
.Li ldc.w Li @ Va aa:16,ccr
whenever the address
.Va aa
is in the top page of memory).
.El
.Pp
.Ss  Xr ld and the Intel 960 Family
You can use the
.Li -A Va architecture
command line option to specify one of the two-letter names identifying members
of the 960 family; the option specifies the desired output target, and warns
of any incompatible instructions in the input files. It also modifies the
linker's search strategy for archive libraries, to support the use of libraries
specific to each particular architecture, by including in the search loop
names suffixed with the string identifying the architecture.
.Pp
For example, if your
.Xr ld
command line included
.Li -ACA
as well as
.Li -ltry
, the linker would look (in its built-in search paths, and in any paths you
specify with
.Li -L )
for a library with the names
.Pp
.Bd -literal -offset indent

try
libtry.a
tryca
libtryca.a

.Ed
.Pp
The first two possibilities would be considered in any event; the last two
are due to the use of
.Li -ACA
\&.
.Pp
You can meaningfully use
.Li -A
more than once on a command line, since the 960 architecture family allows
combination of target architectures; each use will add another pair of name
variants to search for when
.Li -l
specifies a library.
.Pp
.Xr ld
supports the
.Li --relax
option for the i960 family. If you specify
.Li --relax ,
.Xr ld
finds all
.Li balx
and
.Li calx
instructions whose targets are within 24 bits, and turns them into 24-bit
program-counter relative
.Li bal
and
.Li cal
instructions, respectively.
.Xr ld
also turns
.Li cal
instructions into
.Li bal
instructions when it determines that the target subroutine is a leaf routine
(that is, the target subroutine does not itself call any subroutines).
.Pp
.Ss  Xr ld and the Motorola 68HC11 and 68HC12 families
.Em  Linker Relaxation
.Pp
For the Motorola 68HC11,
.Xr ld
can perform these global optimizations when you specify the
.Li --relax
command-line option.
.Pp
.Bl -tag -width Ds
.It  relaxing address modes
.Xr ld
finds all
.Li jsr
and
.Li jmp
instructions whose targets are within eight bits, and turns them into eight-bit
program-counter relative
.Li bsr
and
.Li bra
instructions, respectively.
.Pp
.Xr ld
also looks at all 16-bit extended addressing modes and transforms them in
a direct addressing mode when the address is in page 0 (between 0 and 0x0ff).
.Pp
.It  relaxing gcc instruction group
When
.Xr gcc
is called with
.Op -mrelax ,
it can emit group of instructions that the linker can optimize to use a 68HC11
direct addressing mode. These instructions consists of
.Li bclr
or
.Li bset
instructions.
.Pp
.El
.Em  Trampoline Generation
.Pp
For 68HC11 and 68HC12,
.Xr ld
can generate trampoline code to call a far function using a normal
.Li jsr
instruction. The linker will also change the relocation to some far function
to use the trampoline address instead of the function address. This is typically
the case when a pointer to a function is taken. The pointer will in fact point
to the function trampoline.
.Pp
The
.Li --pic-veneer
switch makes the linker use PIC sequences for ARM/Thumb interworking veneers,
even if the rest of the binary is not PIC. This avoids problems on uClinux
targets where
.Li --emit-relocs
is used to generate relocatable binaries.
.Pp
.Ss  Xr ld and the ARM family
For the ARM,
.Xr ld
will generate code stubs to allow functions calls between ARM and Thumb code.
These stubs only work with code that has been compiled and assembled with
the
.Li -mthumb-interwork
command line option. If it is necessary to link with old ARM object files
or libraries, which have not been compiled with the -mthumb-interwork option
then the
.Li --support-old-code
command line switch should be given to the linker. This will make it generate
larger stub functions which will work with non-interworking aware ARM code.
Note, however, the linker does not support generating stubs for function calls
to non-interworking aware Thumb code.
.Pp
The
.Li --thumb-entry
switch is a duplicate of the generic
.Li --entry
switch, in that it sets the program's starting address. But it also sets the
bottom bit of the address, so that it can be branched to using a BX instruction,
and the program will start executing in Thumb mode straight away.
.Pp
The
.Li --be8
switch instructs
.Xr ld
to generate BE8 format executables. This option is only valid when linking
big-endian objects. The resulting image will contain big-endian data and little-endian
code.
.Pp
The
.Li R_ARM_TARGET1
relocation is typically used for entries in the
.Li .init_array
section. It is interpreted as either
.Li R_ARM_REL32
or
.Li R_ARM_ABS32 ,
depending on the target. The
.Li --target1-rel
and
.Li --target1-abs
switches override the default.
.Pp
The
.Li --target2=type
switch overrides the default definition of the
.Li R_ARM_TARGET2
relocation. Valid values for
.Li type ,
their meanings, and target defaults are as follows:
.Bl -tag -width Ds
.It  rel
.Li R_ARM_REL32
(arm*-*-elf, arm*-*-eabi)
.It  abs
.Li R_ARM_ABS32
(arm*-*-symbianelf)
.It  got-rel
.Li R_ARM_GOT_PREL
(arm*-*-linux, arm*-*-*bsd)
.El
.Pp
The
.Li R_ARM_V4BX
relocation (defined by the ARM AAELF specification) enables objects compiled
for the ARMv4 architecture to be interworking-safe when linked with other
objects compiled for ARMv4t, but also allows pure ARMv4 binaries to be built
from the same ARMv4 objects.
.Pp
In the latter case, the switch
.Op --fix-v4bx
must be passed to the linker, which causes v4t
.Li BX rM
instructions to be rewritten as
.Li MOV PC,rM ,
since v4 processors do not have a
.Li BX
instruction.
.Pp
In the former case, the switch should not be used, and
.Li R_ARM_V4BX
relocations are ignored.
.Pp
The
.Li --use-blx
switch enables the linker to use ARM/Thumb BLX instructions (available on
ARMv5t and above) in various situations. Currently it is used to perform calls
via the PLT from Thumb code using BLX rather than using BX and a mode-switching
stub before each PLT entry. This should lead to such calls executing slightly
faster.
.Pp
This option is enabled implicitly for SymbianOS, so there is no need to specify
it if you are using that target.
.Pp
The
.Li --vfp11-denorm-fix
switch enables a link-time workaround for a bug in certain VFP11 coprocessor
hardware, which sometimes allows instructions with denorm operands (which
must be handled by support code) to have those operands overwritten by subsequent
instructions before the support code can read the intended values.
.Pp
The bug may be avoided in scalar mode if you allow at least one intervening
instruction between a VFP11 instruction which uses a register and another
instruction which writes to the same register, or at least two intervening
instructions if vector mode is in use. The bug only affects full-compliance
floating-point mode: you do not need this workaround if you are using "runfast"
mode. Please contact ARM for further details.
.Pp
If you know you are using buggy VFP11 hardware, you can enable this workaround
by specifying the linker option
.Li --vfp-denorm-fix=scalar
if you are using the VFP11 scalar mode only, or
.Li --vfp-denorm-fix=vector
if you are using vector mode (the latter also works for scalar code). The
default is
.Li --vfp-denorm-fix=none .
.Pp
If the workaround is enabled, instructions are scanned for potentially-troublesome
sequences, and a veneer is created for each such sequence which may trigger
the erratum. The veneer consists of the first instruction of the sequence
and a branch back to the subsequent instruction. The original instruction
is then replaced with a branch to the veneer. The extra cycles required to
call and return from the veneer are sufficient to avoid the erratum in both
the scalar and vector cases.
.Pp
The
.Li --no-enum-size-warning
switch prevents the linker from warning when linking object files that specify
incompatible EABI enumeration size attributes. For example, with this switch
enabled, linking of an object file using 32-bit enumeration values with another
using enumeration values fitted into the smallest possible space will not
be diagnosed.
.Pp
.Ss  Xr ld and HPPA 32-bit ELF Support
When generating a shared library,
.Xr ld
will by default generate import stubs suitable for use with a single sub-space
application. The
.Li --multi-subspace
switch causes
.Xr ld
to generate export stubs, and different (larger) import stubs suitable for
use with multiple sub-spaces.
.Pp
Long branch stubs and import/export stubs are placed by
.Xr ld
in stub sections located between groups of input sections.
.Li --stub-group-size
specifies the maximum size of a group of input sections handled by one stub
section. Since branch offsets are signed, a stub section may serve two groups
of input sections, one group before the stub section, and one group after
it. However, when using conditional branches that require stubs, it may be
better (for branch prediction) that stub sections only serve one group of
input sections. A negative value for
.Li N
chooses this scheme, ensuring that branches to stubs always use a negative
offset. Two special values of
.Li N
are recognized,
.Li 1
and
.Li -1 .
These both instruct
.Xr ld
to automatically size input section groups for the branch types detected,
with the same behaviour regarding stub placement as other positive or negative
values of
.Li N
respectively.
.Pp
Note that
.Li --stub-group-size
does not split input sections. A single input section larger than the group
size specified will of course create a larger group (of one section). If input
sections are too large, it may not be possible for a branch to reach its stub.
.Pp
.Ss  Li ld and MMIX
For MMIX, there is a choice of generating
.Li ELF
object files or
.Li mmo
object files when linking. The simulator
.Li mmix
understands the
.Li mmo
format. The binutils
.Li objcopy
utility can translate between the two formats.
.Pp
There is one special section, the
.Li .MMIX.reg_contents
section. Contents in this section is assumed to correspond to that of global
registers, and symbols referring to it are translated to special symbols,
equal to registers. In a final link, the start address of the
.Li .MMIX.reg_contents
section corresponds to the first allocated global register multiplied by 8.
Register
.Li $255
is not included in this section; it is always set to the program entry, which
is at the symbol
.Li Main
for
.Li mmo
files.
.Pp
Symbols with the prefix
.Li __.MMIX.start. ,
for example
.Li __.MMIX.start..text
and
.Li __.MMIX.start..data
are special; there must be only one each, even if they are local. The default
linker script uses these to set the default start address of a section.
.Pp
Initial and trailing multiples of zero-valued 32-bit words in a section, are
left out from an mmo file.
.Pp
.Ss  Li ld and MSP430
For the MSP430 it is possible to select the MPU architecture. The flag
.Li -m [mpu type]
will select an appropriate linker script for selected MPU type. (To get a
list of known MPUs just pass
.Li -m help
option to the linker).
.Pp
The linker will recognize some extra sections which are MSP430 specific:
.Pp
.Bl -tag -width Ds
.It  Li .vectors
Defines a portion of ROM where interrupt vectors located.
.Pp
.It  Li .bootloader
Defines the bootloader portion of the ROM (if applicable). Any code in this
section will be uploaded to the MPU.
.Pp
.It  Li .infomem
Defines an information memory section (if applicable). Any code in this section
will be uploaded to the MPU.
.Pp
.It  Li .infomemnobits 
This is the same as the
.Li .infomem
section except that any code in this section will not be uploaded to the MPU.
.Pp
.It  Li .noinit
Denotes a portion of RAM located above
.Li .bss
section.
.Pp
The last two sections are used by gcc.
.El
.Pp
.Ss  Xr ld and PowerPC 32-bit ELF Support
Branches on PowerPC processors are limited to a signed 26-bit displacement,
which may result in
.Xr ld
giving
.Li relocation truncated to fit
errors with very large programs.
.Li --relax
enables the generation of trampolines that can access the entire 32-bit address
space. These trampolines are inserted at section boundaries, so may not themselves
be reachable if an input section exceeds 33M in size.
.Pp
.Bl -tag -width Ds
.It  --bss-plt
Current PowerPC GCC accepts a
.Li -msecure-plt
option that generates code capable of using a newer PLT and GOT layout that
has the security advantage of no executable section ever needing to be writable
and no writable section ever being executable. PowerPC
.Xr ld
will generate this layout, including stubs to access the PLT, if all input
files (including startup and static libraries) were compiled with
.Li -msecure-plt .
.Li --bss-plt
forces the old BSS PLT (and GOT layout) which can give slightly better performance.
.Pp
.It  --secure-plt
.Xr ld
will use the new PLT and GOT layout if it is linking new
.Li -fpic
or
.Li -fPIC
code, but does not do so automatically when linking non-PIC code. This option
requests the new PLT and GOT layout. A warning will be given if some object
file requires the old style BSS PLT.
.Pp
.It  --sdata-got
The new secure PLT and GOT are placed differently relative to other sections
compared to older BSS PLT and GOT placement. The location of
.Li .plt
must change because the new secure PLT is an initialized section while the
old PLT is uninitialized. The reason for the
.Li .got
change is more subtle: The new placement allows
.Li .got
to be read-only in applications linked with
.Li -z relro -z now .
However, this placement means that
.Li .sdata
cannot always be used in shared libraries, because the PowerPC ABI accesses
.Li .sdata
in shared libraries from the GOT pointer.
.Li --sdata-got
forces the old GOT placement. PowerPC GCC doesn't use
.Li .sdata
in shared libraries, so this option is really only useful for other compilers
that may do so.
.Pp
.It  --emit-stub-syms
This option causes
.Xr ld
to label linker stubs with a local symbol that encodes the stub type and destination.
.Pp
.It  --no-tls-optimize
PowerPC
.Xr ld
normally performs some optimization of code sequences used to access Thread-Local
Storage. Use this option to disable the optimization.
.El
.Pp
.Ss  Xr ld and PowerPC64 64-bit ELF Support
.Bl -tag -width Ds
.It  --stub-group-size
Long branch stubs, PLT call stubs and TOC adjusting stubs are placed by
.Xr ld
in stub sections located between groups of input sections.
.Li --stub-group-size
specifies the maximum size of a group of input sections handled by one stub
section. Since branch offsets are signed, a stub section may serve two groups
of input sections, one group before the stub section, and one group after
it. However, when using conditional branches that require stubs, it may be
better (for branch prediction) that stub sections only serve one group of
input sections. A negative value for
.Li N
chooses this scheme, ensuring that branches to stubs always use a negative
offset. Two special values of
.Li N
are recognized,
.Li 1
and
.Li -1 .
These both instruct
.Xr ld
to automatically size input section groups for the branch types detected,
with the same behaviour regarding stub placement as other positive or negative
values of
.Li N
respectively.
.Pp
Note that
.Li --stub-group-size
does not split input sections. A single input section larger than the group
size specified will of course create a larger group (of one section). If input
sections are too large, it may not be possible for a branch to reach its stub.
.Pp
.It  --emit-stub-syms
This option causes
.Xr ld
to label linker stubs with a local symbol that encodes the stub type and destination.
.Pp
.It  --dotsyms, --no-dotsyms
These two options control how
.Xr ld
interprets version patterns in a version script. Older PowerPC64 compilers
emitted both a function descriptor symbol with the same name as the function,
and a code entry symbol with the name prefixed by a dot (
.Li . ) .
To properly version a function
.Li foo ,
the version script thus needs to control both
.Li foo
and
.Li .foo .
The option
.Li --dotsyms ,
on by default, automatically adds the required dot-prefixed patterns. Use
.Li --no-dotsyms
to disable this feature.
.Pp
.It  --no-tls-optimize
PowerPC64
.Xr ld
normally performs some optimization of code sequences used to access Thread-Local
Storage. Use this option to disable the optimization.
.Pp
.It  --no-opd-optimize
PowerPC64
.Xr ld
normally removes
.Li .opd
section entries corresponding to deleted link-once functions, or functions
removed by the action of
.Li --gc-sections
or linker scrip
.Li /DISCARD/ .
Use this option to disable
.Li .opd
optimization.
.Pp
.It  --non-overlapping-opd
Some PowerPC64 compilers have an option to generate compressed
.Li .opd
entries spaced 16 bytes apart, overlapping the third word, the static chain
pointer (unused in C) with the first word of the next entry. This option expands
such entries to the full 24 bytes.
.Pp
.It  --no-toc-optimize
PowerPC64
.Xr ld
normally removes unused
.Li .toc
section entries. Such entries are detected by examining relocations that reference
the TOC in code sections. A reloc in a deleted code section marks a TOC word
as unneeded, while a reloc in a kept code section marks a TOC word as needed.
Since the TOC may reference itself, TOC relocs are also examined. TOC words
marked as both needed and unneeded will of course be kept. TOC words without
any referencing reloc are assumed to be part of a multi-word entry, and are
kept or discarded as per the nearest marked preceding word. This works reliably
for compiler generated code, but may be incorrect if assembly code is used
to insert TOC entries. Use this option to disable the optimization.
.Pp
.It  --no-multi-toc
By default, PowerPC64 GCC generates code for a TOC model where TOC entries
are accessed with a 16-bit offset from r2. This limits the total TOC size
to 64K. PowerPC64
.Xr ld
extends this limit by grouping code sections such that each group uses less
than 64K for its TOC entries, then inserts r2 adjusting stubs between inter-group
calls.
.Xr ld
does not split apart input sections, so cannot help if a single input file
has a
.Li .toc
section that exceeds 64K, most likely from linking multiple files with
.Xr ld -r .
Use this option to turn off this feature.
.El
.Pp
.Ss  Xr ld and SPU ELF Support
.Bl -tag -width Ds
.It  --plugin
This option marks an executable as a PIC plugin module.
.Pp
.It  --no-overlays
Normally,
.Xr ld
recognizes calls to functions within overlay regions, and redirects such calls
to an overlay manager via a stub.
.Xr ld
also provides a built-in overlay manager. This option turns off all this special
overlay handling.
.Pp
.It  --emit-stub-syms
This option causes
.Xr ld
to label overlay stubs with a local symbol that encodes the stub type and
destination.
.Pp
.It  --extra-overlay-stubs
This option causes
.Xr ld
to add overlay call stubs on all function calls out of overlay regions. Normally
stubs are not added on calls to non-overlay regions.
.Pp
.It  --local-store=lo:hi
.Xr ld
usually checks that a final executable for SPU fits in the address range 0
to 256k. This option may be used to change the range. Disable the check entirely
with
.Op --local-store=0:0 .
.Pp
.It  --stack-analysis
SPU local store space is limited. Over-allocation of stack space unnecessarily
limits space available for code and data, while under-allocation results in
runtime failures. If given this option,
.Xr ld
will provide an estimate of maximum stack usage.
.Xr ld
does this by examining symbols in code sections to determine the extents of
functions, and looking at function prologues for stack adjusting instructions.
A call-graph is created by looking for relocations on branch instructions.
The graph is then searched for the maximum stack usage path. Note that this
analysis does not find calls made via function pointers, and does not handle
recursion and other cycles in the call graph. Stack usage may be under-estimated
if your code makes such calls. Also, stack usage for dynamic allocation, e.g.
alloca, will not be detected. If a link map is requested, detailed information
about each function's stack usage and calls will be given.
.Pp
.It  --emit-stack-syms
This option, if given along with
.Op --stack-analysis
will result in
.Xr ld
emitting stack sizing symbols for each function. These take the form
.Li __stack_<function_name>
for global functions, and
.Li __stack_<number>_<function_name>
for static functions.
.Li <number>
is the section id in hex. The value of such symbols is the stack requirement
for the corresponding function. The symbol size will be zero, type
.Li STT_NOTYPE ,
binding
.Li STB_LOCAL ,
and section
.Li SHN_ABS .
.El
.Pp
.Ss  Xr ld's Support for Various TI COFF Versions
The
.Li --format
switch allows selection of one of the various TI COFF versions. The latest
of this writing is 2; versions 0 and 1 are also supported. The TI COFF versions
also vary in header byte-order format;
.Xr ld
will read any version or byte order, but the output header format depends
on the default specified by the specific target.
.Pp
.Ss  Xr ld and WIN32 (cygwin/mingw)
This section describes some of the win32 specific
.Xr ld
issues. See Options,,Command Line Options for detailed description of the
command line options mentioned here.
.Pp
.Bl -tag -width Ds
.It  import libraries 
The standard Windows linker creates and uses so-called import libraries, which
contains information for linking to dll's. They are regular static archives
and are handled as any other static archive. The cygwin and mingw ports of
.Xr ld
have specific support for creating such libraries provided with the
.Li --out-implib
command line option.
.Pp
.It  exporting DLL symbols 
The cygwin/mingw
.Xr ld
has several ways to export symbols for dll's.
.Pp
.Bl -tag -width Ds
.It  using auto-export functionality
By default
.Xr ld
exports symbols with the auto-export functionality, which is controlled by
the following command line options:
.Pp
.Bl -bullet
.It
--export-all-symbols [This is the default]
.It
--exclude-symbols
.It
--exclude-libs
.El
.Pp
If, however,
.Li --export-all-symbols
is not given explicitly on the command line, then the default auto-export
behavior will be
.Em disabled
if either of the following are true:
.Pp
.Bl -bullet
.It
A DEF file is used.
.It
Any symbol in any object file was marked with the __declspec(dllexport) attribute.
.El
.Pp
.It  using a DEF file 
Another way of exporting symbols is using a DEF file. A DEF file is an ASCII
file containing definitions of symbols which should be exported when a dll
is created. Usually it is named
.Li <dll name>.def
and is added as any other object file to the linker's command line. The file's
name must end in
.Li .def
or
.Li .DEF .
.Pp
.Bd -literal -offset indent
gcc -o <output> <objectfiles> <dll name>.def
.Ed
.Pp
Using a DEF file turns off the normal auto-export behavior, unless the
.Li --export-all-symbols
option is also used.
.Pp
Here is an example of a DEF file for a shared library called
.Li xyz.dll :
.Pp
.Bd -literal -offset indent
LIBRARY "xyz.dll" BASE=0x20000000

EXPORTS
foo
bar
_bar = bar
another_foo = abc.dll.afoo
var1 DATA
.Ed
.Pp
This example defines a DLL with a non-default base address and five symbols
in the export table. The third exported symbol
.Li _bar
is an alias for the second. The fourth symbol,
.Li another_foo
is resolved by "forwarding" to another module and treating it as an alias
for
.Li afoo
exported from the DLL
.Li abc.dll .
The final symbol
.Li var1
is declared to be a data object.
.Pp
The optional
.Li LIBRARY <name>
command indicates the
.Em internal
name of the output DLL. If
.Li <name>
does not include a suffix, the default library suffix,
.Li .DLL
is appended.
.Pp
When the .DEF file is used to build an application, rather than a library,
the
.Li NAME <name>
command should be used instead of
.Li LIBRARY .
If
.Li <name>
does not include a suffix, the default executable suffix,
.Li .EXE
is appended.
.Pp
With either
.Li LIBRARY <name>
or
.Li NAME <name>
the optional specification
.Li BASE = <number>
may be used to specify a non-default base address for the image.
.Pp
If neither
.Li LIBRARY <name>
nor
.Li NAME <name>
is specified, or they specify an empty string, the internal name is the same
as the filename specified on the command line.
.Pp
The complete specification of an export symbol is:
.Pp
.Bd -literal -offset indent
EXPORTS
  ( (  ( <name1> [ = <name2> ] )
     | ( <name1> = <module-name> . <external-name>))
  [ @ <integer> ] [NONAME] [DATA] [CONSTANT] [PRIVATE] ) *
.Ed
.Pp
Declares
.Li <name1>
as an exported symbol from the DLL, or declares
.Li <name1>
as an exported alias for
.Li <name2> ;
or declares
.Li <name1>
as a "forward" alias for the symbol
.Li <external-name>
in the DLL
.Li <module-name> .
Optionally, the symbol may be exported by the specified ordinal
.Li <integer>
alias.
.Pp
The optional keywords that follow the declaration indicate:
.Pp
.Li NONAME :
Do not put the symbol name in the DLL's export table. It will still be exported
by its ordinal alias (either the value specified by the .def specification
or, otherwise, the value assigned by the linker). The symbol name, however,
does remain visible in the import library (if any), unless
.Li PRIVATE
is also specified.
.Pp
.Li DATA :
The symbol is a variable or object, rather than a function. The import lib
will export only an indirect reference to
.Li foo
as the symbol
.Li _imp__foo
(ie,
.Li foo
must be resolved as
.Li *_imp__foo ) .
.Pp
.Li CONSTANT :
Like
.Li DATA ,
but put the undecorated
.Li foo
as well as
.Li _imp__foo
into the import library. Both refer to the read-only import address table's
pointer to the variable, not to the variable itself. This can be dangerous.
If the user code fails to add the
.Li dllimport
attribute and also fails to explicitly add the extra indirection that the
use of the attribute enforces, the application will behave unexpectedly.
.Pp
.Li PRIVATE :
Put the symbol in the DLL's export table, but do not put it into the static
import library used to resolve imports at link time. The symbol can still
be imported using the
.Li LoadLibrary/GetProcAddress
API at runtime or by by using the GNU ld extension of linking directly to
the DLL without an import library. See ld/deffilep.y in the binutils sources
for the full specification of other DEF file statements
.Pp
While linking a shared dll,
.Xr ld
is able to create a DEF file with the
.Li --output-def <file>
command line option.
.Pp
.It  Using decorations
Another way of marking symbols for export is to modify the source code itself,
so that when building the DLL each symbol to be exported is declared as:
.Pp
.Bd -literal -offset indent
__declspec(dllexport) int a_variable
__declspec(dllexport) void a_function(int with_args)
.Ed
.Pp
All such symbols will be exported from the DLL. If, however, any of the object
files in the DLL contain symbols decorated in this way, then the normal auto-export
behavior is disabled, unless the
.Li --export-all-symbols
option is also used.
.Pp
Note that object files that wish to access these symbols must
.Em not
decorate them with dllexport. Instead, they should use dllimport, instead:
.Pp
.Bd -literal -offset indent
__declspec(dllimport) int a_variable
__declspec(dllimport) void a_function(int with_args)
.Ed
.Pp
This complicates the structure of library header files, because when included
by the library itself the header must declare the variables and functions
as dllexport, but when included by client code the header must declare them
as dllimport. There are a number of idioms that are typically used to do this;
often client code can omit the __declspec() declaration completely. See
.Li --enable-auto-import
and
.Li automatic data imports
for more information.
.El
.Pp
.It  automatic data imports
The standard Windows dll format supports data imports from dlls only by adding
special decorations (dllimport/dllexport), which let the compiler produce
specific assembler instructions to deal with this issue. This increases the
effort necessary to port existing Un*x code to these platforms, especially
for large c++ libraries and applications. The auto-import feature, which was
initially provided by Paul Sokolovsky, allows one to omit the decorations
to achieve a behavior that conforms to that on POSIX/Un*x platforms. This
feature is enabled with the
.Li --enable-auto-import
command-line option, although it is enabled by default on cygwin/mingw. The
.Li --enable-auto-import
option itself now serves mainly to suppress any warnings that are ordinarily
emitted when linked objects trigger the feature's use.
.Pp
auto-import of variables does not always work flawlessly without additional
assistance. Sometimes, you will see this message
.Pp
"variable '<var>' can't be auto-imported. Please read the documentation for
ld's
.Li --enable-auto-import
for details."
.Pp
The
.Li --enable-auto-import
documentation explains why this error occurs, and several methods that can
be used to overcome this difficulty. One of these methods is the
.Em runtime pseudo-relocs
feature, described below.
.Pp
For complex variables imported from DLLs (such as structs or classes), object
files typically contain a base address for the variable and an offset (
.Em addend )
within the variable--to specify a particular field or public member, for instance.
Unfortunately, the runtime loader used in win32 environments is incapable
of fixing these references at runtime without the additional information supplied
by dllimport/dllexport decorations. The standard auto-import feature described
above is unable to resolve these references.
.Pp
The
.Li --enable-runtime-pseudo-relocs
switch allows these references to be resolved without error, while leaving
the task of adjusting the references themselves (with their non-zero addends)
to specialized code provided by the runtime environment. Recent versions of
the cygwin and mingw environments and compilers provide this runtime support;
older versions do not. However, the support is only necessary on the developer's
platform; the compiled result will run without error on an older system.
.Pp
.Li --enable-runtime-pseudo-relocs
is not the default; it must be explicitly enabled as needed.
.Pp
.It  direct linking to a dll
The cygwin/mingw ports of
.Xr ld
support the direct linking, including data symbols, to a dll without the usage
of any import libraries. This is much faster and uses much less memory than
does the traditional import library method, especially when linking large
libraries or applications. When
.Xr ld
creates an import lib, each function or variable exported from the dll is
stored in its own bfd, even though a single bfd could contain many exports.
The overhead involved in storing, loading, and processing so many bfd's is
quite large, and explains the tremendous time, memory, and storage needed
to link against particularly large or complex libraries when using import
libs.
.Pp
Linking directly to a dll uses no extra command-line switches other than
.Li -L
and
.Li -l ,
because
.Xr ld
already searches for a number of names to match each library. All that is
needed from the developer's perspective is an understanding of this search,
in order to force ld to select the dll instead of an import library.
.Pp
For instance, when ld is called with the argument
.Li -lxxx
it will attempt to find, in the first directory of its search path,
.Pp
.Bd -literal -offset indent
libxxx.dll.a
xxx.dll.a
libxxx.a
xxx.lib
cygxxx.dll (*)
libxxx.dll
xxx.dll
.Ed
.Pp
before moving on to the next directory in the search path.
.Pp
(*) Actually, this is not
.Li cygxxx.dll
but in fact is
.Li <prefix>xxx.dll ,
where
.Li <prefix>
is set by the
.Xr ld
option
.Li --dll-search-prefix=<prefix> .
In the case of cygwin, the standard gcc spec file includes
.Li --dll-search-prefix=cyg ,
so in effect we actually search for
.Li cygxxx.dll .
.Pp
Other win32-based unix environments, such as mingw or pw32, may use other
.Li <prefix>
es, although at present only cygwin makes use of this feature. It was originally
intended to help avoid name conflicts among dll's built for the various win32/un*x
environments, so that (for example) two versions of a zlib dll could coexist
on the same machine.
.Pp
The generic cygwin/mingw path layout uses a
.Li bin
directory for applications and dll's and a
.Li lib
directory for the import libraries (using cygwin nomenclature):
.Pp
.Bd -literal -offset indent
bin/
        cygxxx.dll
lib/
        libxxx.dll.a   (in case of dll's)
        libxxx.a       (in case of static archive) 
.Ed
.Pp
Linking directly to a dll without using the import library can be done two
ways:
.Pp
1. Use the dll directly by adding the
.Li bin
path to the link line
.Bd -literal -offset indent
gcc -Wl,-verbose  -o a.exe -L../bin/ -lxxx
.Ed
.Pp
However, as the dll's often have version numbers appended to their names (
.Li cygncurses-5.dll )
this will often fail, unless one specifies
.Li -L../bin -lncurses-5
to include the version. Import libs are generally not versioned, and do not
have this difficulty.
.Pp
2. Create a symbolic link from the dll to a file in the
.Li lib
directory according to the above mentioned search pattern. This should be
used to avoid unwanted changes in the tools needed for making the app/dll.
.Pp
.Bd -literal -offset indent
ln -s bin/cygxxx.dll lib/[cyg|lib|]xxx.dll[.a]
.Ed
.Pp
Then you can link without any make environment changes.
.Pp
.Bd -literal -offset indent
gcc -Wl,-verbose  -o a.exe -L../lib/ -lxxx
.Ed
.Pp
This technique also avoids the version number problems, because the following
is perfectly legal
.Pp
.Bd -literal -offset indent
bin/
        cygxxx-5.dll
lib/
        libxxx.dll.a -> ../bin/cygxxx-5.dll 
.Ed
.Pp
Linking directly to a dll without using an import lib will work even when
auto-import features are exercised, and even when
.Li --enable-runtime-pseudo-relocs
is used.
.Pp
Given the improvements in speed and memory usage, one might justifiably wonder
why import libraries are used at all. There are three reasons:
.Pp
1. Until recently, the link-directly-to-dll functionality did
.Em not
work with auto-imported data.
.Pp
2. Sometimes it is necessary to include pure static objects within the import
library (which otherwise contains only bfd's for indirection symbols that
point to the exports of a dll). Again, the import lib for the cygwin kernel
makes use of this ability, and it is not possible to do this without an import
lib.
.Pp
3. Symbol aliases can only be resolved using an import lib. This is critical
when linking against OS-supplied dll's (eg, the win32 API) in which symbols
are usually exported as undecorated aliases of their stdcall-decorated assembly
names.
.Pp
So, import libs are not going away. But the ability to replace true import
libs with a simple symbolic link to (or a copy of) a dll, in many cases, is
a useful addition to the suite of tools binutils makes available to the win32
developer. Given the massive improvements in memory requirements during linking,
storage requirements, and linking speed, we expect that many developers will
soon begin to use this feature whenever possible.
.Pp
.It  symbol aliasing 
.Bl -tag -width Ds
.It  adding additional names 
Sometimes, it is useful to export symbols with additional names. A symbol
.Li foo
will be exported as
.Li foo ,
but it can also be exported as
.Li _foo
by using special directives in the DEF file when creating the dll. This will
affect also the optional created import library. Consider the following DEF
file:
.Pp
.Bd -literal -offset indent
LIBRARY "xyz.dll" BASE=0x61000000

EXPORTS
foo 
_foo = foo
.Ed
.Pp
The line
.Li _foo = foo
maps the symbol
.Li foo
to
.Li _foo .
.Pp
Another method for creating a symbol alias is to create it in the source code
using the "weak" attribute:
.Pp
.Bd -literal -offset indent
void foo () { /* Do something.  */; } 
void _foo () __attribute__ ((weak, alias ("foo")));
.Ed
.Pp
See the gcc manual for more information about attributes and weak symbols.
.Pp
.It  renaming symbols
Sometimes it is useful to rename exports. For instance, the cygwin kernel
does this regularly. A symbol
.Li _foo
can be exported as
.Li foo
but not as
.Li _foo
by using special directives in the DEF file. (This will also affect the import
library, if it is created). In the following example:
.Pp
.Bd -literal -offset indent
LIBRARY "xyz.dll" BASE=0x61000000

EXPORTS
_foo = foo
.Ed
.Pp
The line
.Li _foo = foo
maps the exported symbol
.Li foo
to
.Li _foo .
.El
.Pp
Note: using a DEF file disables the default auto-export behavior, unless the
.Li --export-all-symbols
command line option is used. If, however, you are trying to rename symbols,
then you should list
.Em all
desired exports in the DEF file, including the symbols that are not being
renamed, and do
.Em not
use the
.Li --export-all-symbols
option. If you list only the renamed symbols in the DEF file, and use
.Li --export-all-symbols
to handle the other symbols, then the both the new names
.Em and
the original names for the renamed symbols will be exported. In effect, you'd
be aliasing those symbols, not renaming them, which is probably not what you
wanted.
.Pp
.It  weak externals
The Windows object format, PE, specifies a form of weak symbols called weak
externals. When a weak symbol is linked and the symbol is not defined, the
weak symbol becomes an alias for some other symbol. There are three variants
of weak externals:
.Bl -bullet
.It
Definition is searched for in objects and libraries, historically
called lazy externals.
.It
Definition is searched for only in other objects, not in libraries.
This form is not presently implemented.
.It
No search; the symbol is an alias. This form is not presently
implemented.
.El
As a GNU extension, weak symbols that do not specify an alternate symbol are
supported. If the symbol is undefined when linking, the symbol uses a default
value.
.El
.Pp
.Ss  Li ld and Xtensa Processors
The default
.Xr ld
behavior for Xtensa processors is to interpret
.Li SECTIONS
commands so that lists of explicitly named sections in a specification with
a wildcard file will be interleaved when necessary to keep literal pools within
the range of PC-relative load offsets. For example, with the command:
.Pp
.Bd -literal -offset indent
SECTIONS
{
  .text : {
    *(.literal .text)
  }
}
.Ed
.Pp
.Xr ld
may interleave some of the
.Li .literal
and
.Li .text
sections from different object files to ensure that the literal pools are
within the range of PC-relative load offsets. A valid interleaving might place
the
.Li .literal
sections from an initial group of files followed by the
.Li .text
sections of that group of files. Then, the
.Li .literal
sections from the rest of the files and the
.Li .text
sections from the rest of the files would follow.
.Pp
Relaxation is enabled by default for the Xtensa version of
.Xr ld
and provides two important link-time optimizations. The first optimization
is to combine identical literal values to reduce code size. A redundant literal
will be removed and all the
.Li L32R
instructions that use it will be changed to reference an identical literal,
as long as the location of the replacement literal is within the offset range
of all the
.Li L32R
instructions. The second optimization is to remove unnecessary overhead from
assembler-generated \(lqlongcall\(rq sequences of
.Li L32R
/
.Li CALLX Va n
when the target functions are within range of direct
.Li CALL Va n
instructions.
.Pp
For each of these cases where an indirect call sequence can be optimized to
a direct call, the linker will change the
.Li CALLX Va n
instruction to a
.Li CALL Va n
instruction, remove the
.Li L32R
instruction, and remove the literal referenced by the
.Li L32R
instruction if it is not used for anything else. Removing the
.Li L32R
instruction always reduces code size but can potentially hurt performance
by changing the alignment of subsequent branch targets. By default, the linker
will always preserve alignments, either by switching some instructions between
24-bit encodings and the equivalent density instructions or by inserting a
no-op in place of the
.Li L32R
instruction that was removed. If code size is more important than performance,
the
.Op --size-opt
option can be used to prevent the linker from widening density instructions
or inserting no-ops, except in a few cases where no-ops are required for correctness.
.Pp
The following Xtensa-specific command-line options can be used to control
the linker:
.Pp
.Bl -tag -width Ds
.It  --no-relax
Since the Xtensa version of
.Li ld
enables the
.Op --relax
option by default, the
.Op --no-relax
option is provided to disable relaxation.
.Pp
.It  --size-opt
When optimizing indirect calls to direct calls, optimize for code size more
than performance. With this option, the linker will not insert no-ops or widen
density instructions to preserve branch target alignment. There may still
be some cases where no-ops are required to preserve the correctness of the
code.
.El
.Pp
.Sh  BFD
The linker accesses object and archive files using the BFD libraries. These
libraries allow the linker to use the same routines to operate on object files
whatever the object file format. A different object file format can be supported
simply by creating a new BFD back end and adding it to the library. To conserve
runtime memory, however, the linker and associated tools are usually configured
to support only a subset of the object file formats available. You can use
.Li objdump -i
(see Section
.Dq objdump )
to list all the formats available for your configuration.
.Pp
As with most implementations, BFD is a compromise between several conflicting
requirements. The major factor influencing BFD design was efficiency: any
time used converting between formats is time which would not have been spent
had BFD not been involved. This is partly offset by abstraction payback; since
BFD simplifies applications and back ends, more time and care may be spent
optimizing algorithms for a greater speed.
.Pp
One minor artifact of the BFD solution which you should bear in mind is the
potential for information loss. There are two places where useful information
can be lost using the BFD mechanism: during conversion and during output.See Section
.Dq BFD information loss .
.Pp
.Ss  How It Works: An Outline of BFD
When an object file is opened, BFD subroutines automatically determine the
format of the input object file. They then build a descriptor in memory with
pointers to routines that will be used to access elements of the object file's
data structures.
.Pp
As different information from the object files is required, BFD reads from
different sections of the file and processes them. For example, a very common
operation for the linker is processing symbol tables. Each BFD back end provides
a routine for converting between the object file's representation of symbols
and an internal canonical format. When the linker asks for the symbol table
of an object file, it calls through a memory pointer to the routine from the
relevant BFD back end which reads and converts the table into a canonical
form. The linker then operates upon the canonical form. When the link is finished
and the linker writes the output file's symbol table, another BFD back end
routine is called to take the newly created symbol table and convert it into
the chosen output format.
.Pp
.Em  Information Loss
.Pp
.Em Information can be lost during output.
The output formats supported by BFD do not provide identical facilities, and
information which can be described in one form has nowhere to go in another
format. One example of this is alignment information in
.Li b.out .
There is nowhere in an
.Li a.out
format file to store alignment information on the contained data, so when
a file is linked from
.Li b.out
and an
.Li a.out
image is produced, alignment information will not propagate to the output
file. (The linker will still use the alignment information internally, so
the link is performed correctly).
.Pp
Another example is COFF section names. COFF files may contain an unlimited
number of sections, each one with a textual section name. If the target of
the link is a format which does not have many sections (e.g.,
.Li a.out )
or has sections without names (e.g., the Oasys format), the link cannot be
done simply. You can circumvent this problem by describing the desired input-to-output
section mapping with the linker command language.
.Pp
.Em Information can be lost during canonicalization.
The BFD internal canonical form of the external formats is not exhaustive;
there are structures in input formats for which there is no direct representation
internally. This means that the BFD back ends cannot maintain all possible
data richness through the transformation between external to internal and
back to external formats.
.Pp
This limitation is only a problem when an application reads one format and
writes another. Each BFD back end is responsible for maintaining as much data
as possible, and the internal BFD canonical form has structures which are
opaque to the BFD core, and exported only to the back ends. When a file is
read in one format, the canonical form is generated for BFD and the application.
At the same time, the back end saves away any information which may otherwise
be lost. If the data is then written back in the same format, the back end
routine will be able to use the canonical form provided by the BFD core as
well as the information it prepared earlier. Since there is a great deal of
commonality between back ends, there is no information lost when linking or
copying big endian COFF to little endian COFF, or
.Li a.out
to
.Li b.out .
When a mixture of formats is linked, the information is only lost from the
files whose format differs from the destination.
.Pp
.Em  The BFD canonical object-file format
.Pp
The greatest potential for loss of information occurs when there is the least
overlap between the information provided by the source format, that stored
by the canonical format, and that needed by the destination format. A brief
description of the canonical form may help you understand which kinds of data
you can count on preserving across conversions.
.Pp
.Bl -tag -width Ds
.It  files
Information stored on a per-file basis includes target machine architecture,
particular implementation format type, a demand pageable bit, and a write
protected bit. Information like Unix magic numbers is not stored here---only
the magic numbers' meaning, so a
.Li ZMAGIC
file would have both the demand pageable bit and the write protected text
bit set. The byte order of the target is stored on a per-file basis, so that
big- and little-endian object files may be used with one another.
.Pp
.It  sections
Each section in the input file contains the name of the section, the section's
original address in the object file, size and alignment information, various
flags, and pointers into other BFD data structures.
.Pp
.It  symbols
Each symbol contains a pointer to the information for the object file which
originally defined it, its name, its value, and various flag bits. When a
BFD back end reads in a symbol table, it relocates all symbols to make them
relative to the base of the section where they were defined. Doing this ensures
that each symbol points to its containing section. Each symbol also has a
varying amount of hidden private data for the BFD back end. Since the symbol
points to the original file, the private data format for that symbol is accessible.
.Li ld
can operate on a collection of symbols of wildly different formats without
problems.
.Pp
Normal global and simple local symbols are maintained on output, so an output
file (no matter its format) will retain symbols pointing to functions and
to global, static, and common variables. Some symbol information is not worth
retaining; in
.Li a.out ,
type information is stored in the symbol table as long symbol names. This
information would be useless to most COFF debuggers; the linker has command
line switches to allow users to throw it away.
.Pp
There is one word of type information within the symbol, so if the format
supports symbol type information within symbols (for example, COFF, IEEE,
Oasys) and the type is simple enough to fit within one word (nearly everything
but aggregates), the information will be preserved.
.Pp
.It  relocation level
Each canonical BFD relocation record contains a pointer to the symbol to relocate
to, the offset of the data to relocate, the section the data is in, and a
pointer to a relocation type descriptor. Relocation is performed by passing
messages through the relocation type descriptor and the symbol pointer. Therefore,
relocations can be performed on output data using a relocation method that
is only available in one of the input formats. For instance, Oasys provides
a byte relocation format. A relocation record requesting this relocation type
would point indirectly to a routine to perform this, so the relocation may
be performed on a byte being written to a 68k COFF file, even though 68k COFF
has no such relocation type.
.Pp
.It  line numbers
Object formats can contain, for debugging purposes, some form of mapping between
symbols, source line numbers, and addresses in the output file. These addresses
have to be relocated along with the symbol information. Each symbol with an
associated list of line number records points to the first record of the list.
The head of a line number list consists of a pointer to the symbol, which
allows finding out the address of the function whose line number is being
described. The rest of the list is made up of pairs: offsets into the section
and line numbers. Any format which can simply derive this information can
pass it successfully between formats (COFF, IEEE and Oasys).
.El
.Pp
.Sh  Reporting Bugs
Your bug reports play an essential role in making
.Xr ld
reliable.
.Pp
Reporting a bug may help you by bringing a solution to your problem, or it
may not. But in any case the principal function of a bug report is to help
the entire community by making the next version of
.Xr ld
work better. Bug reports are your contribution to the maintenance of
.Xr ld .
.Pp
In order for a bug report to serve its purpose, you must include the information
that enables us to fix the bug.
.Pp
.Ss  Have You Found a Bug?
If you are not sure whether you have found a bug, here are some guidelines:
.Pp
.Bl -bullet
.It
If the linker gets a fatal signal, for any input whatever, that is a
.Xr ld
bug. Reliable linkers never crash.
.Pp
.It
If
.Xr ld
produces an error message for valid input, that is a bug.
.Pp
.It
If
.Xr ld
does not produce an error message for invalid input, that may be a bug. In
the general case, the linker can not verify that object files are correct.
.Pp
.It
If you are an experienced user of linkers, your suggestions for improvement
of
.Xr ld
are welcome in any case.
.El
.Pp
.Ss  How to Report Bugs
A number of companies and individuals offer support for GNU products. If you
obtained
.Xr ld
from a support organization, we recommend you contact that organization first.
.Pp
You can find contact information for many support companies and individuals
in the file
.Pa etc/SERVICE
in the GNU Emacs distribution.
.Pp
The fundamental principle of reporting bugs usefully is this:
.Sy report all the facts .
If you are not sure whether to state a fact or leave it out, state it!
.Pp
Often people omit facts because they think they know what causes the problem
and assume that some details do not matter. Thus, you might assume that the
name of a symbol you use in an example does not matter. Well, probably it
does not, but one cannot be sure. Perhaps the bug is a stray memory reference
which happens to fetch from the location where that name is stored in memory;
perhaps, if the name were different, the contents of that location would fool
the linker into doing the right thing despite the bug. Play it safe and give
a specific, complete example. That is the easiest thing for you to do, and
the most helpful.
.Pp
Keep in mind that the purpose of a bug report is to enable us to fix the bug
if it is new to us. Therefore, always write your bug reports on the assumption
that the bug has not been reported previously.
.Pp
Sometimes people give a few sketchy facts and ask, \(lqDoes this ring a bell?\(rq
This cannot help us fix a bug, so it is basically useless. We respond by asking
for enough details to enable us to investigate. You might as well expedite
matters by sending them to begin with.
.Pp
To enable us to fix the bug, you should include all these things:
.Pp
.Bl -bullet
.It
The version of
.Xr ld .
.Xr ld
announces it if you start it with the
.Li --version
argument.
.Pp
Without this, we will not know whether there is any point in looking for the
bug in the current version of
.Xr ld .
.Pp
.It
Any patches you may have applied to the
.Xr ld
source, including any patches made to the
.Li BFD
library.
.Pp
.It
The type of machine you are using, and the operating system name and version
number.
.Pp
.It
What compiler (and its version) was used to compile
.Xr ld
---e.g. \(lq
.Li gcc-2.7
\(rq\&.
.Pp
.It
The command arguments you gave the linker to link your example and observe
the bug. To guarantee you will not omit something important, list them all.
A copy of the Makefile (or the output from make) is sufficient.
.Pp
If we were to try to guess the arguments, we would probably guess wrong and
then we might not encounter the bug.
.Pp
.It
A complete input file, or set of input files, that will reproduce the bug.
It is generally most helpful to send the actual object files provided that
they are reasonably small. Say no more than 10K. For bigger files you can
either make them available by FTP or HTTP or else state that you are willing
to send the object file(s) to whomever requests them. (Note - your email will
be going to a mailing list, so we do not want to clog it up with large attachments).
But small attachments are best.
.Pp
If the source files were assembled using
.Li gas
or compiled using
.Li gcc ,
then it may be OK to send the source files rather than the object files. In
this case, be sure to say exactly what version of
.Li gas
or
.Li gcc
was used to produce the object files. Also say how
.Li gas
or
.Li gcc
were configured.
.Pp
.It
A description of what behavior you observe that you believe is incorrect.
For example, \(lqIt gets a fatal signal.\(rq
.Pp
Of course, if the bug is that
.Xr ld
gets a fatal signal, then we will certainly notice it. But if the bug is incorrect
output, we might not notice unless it is glaringly wrong. You might as well
not give us a chance to make a mistake.
.Pp
Even if the problem you experience is a fatal signal, you should still say
so explicitly. Suppose something strange is going on, such as, your copy of
.Xr ld
is out of sync, or you have encountered a bug in the C library on your system.
(This has happened!) Your copy might crash and ours would not. If you told
us to expect a crash, then when ours fails to crash, we would know that the
bug was not happening for us. If you had not told us to expect a crash, then
we would not be able to draw any conclusion from our observations.
.Pp
.It
If you wish to suggest changes to the
.Xr ld
source, send us context diffs, as generated by
.Li diff
with the
.Li -u ,
.Li -c ,
or
.Li -p
option. Always send diffs from the old file to the new file. If you even discuss
something in the
.Xr ld
source, refer to it by context, not by line number.
.Pp
The line numbers in our development sources will not match those in your sources.
Your line numbers would convey no useful information to us.
.El
.Pp
Here are some things that are not necessary:
.Pp
.Bl -bullet
.It
A description of the envelope of the bug.
.Pp
Often people who encounter a bug spend a lot of time investigating which changes
to the input file will make the bug go away and which changes will not affect
it.
.Pp
This is often time consuming and not very useful, because the way we will
find the bug is by running a single example under the debugger with breakpoints,
not by pure deduction from a series of examples. We recommend that you save
your time for something else.
.Pp
Of course, if you can find a simpler example to report
.Em instead
of the original one, that is a convenience for us. Errors in the output will
be easier to spot, running under the debugger will take less time, and so
on.
.Pp
However, simplification is not vital; if you do not want to do this, report
the bug anyway and send us the entire test case you used.
.Pp
.It
A patch for the bug.
.Pp
A patch for the bug does help us if it is a good one. But do not omit the
necessary information, such as the test case, on the assumption that a patch
is all we need. We might see problems with your patch and decide to fix the
problem another way, or we might not understand it at all.
.Pp
Sometimes with a program as complicated as
.Xr ld
it is very hard to construct an example that will make the program follow
a certain path through the code. If you do not send us the example, we will
not be able to construct one, so we will not be able to verify that the bug
is fixed.
.Pp
And if we cannot understand what bug you are trying to fix, or why your patch
should be an improvement, we will not install it. A test case will help us
to understand.
.Pp
.It
A guess about what the bug is or what it depends on.
.Pp
Such guesses are usually wrong. Even we cannot guess right about such things
without first using the debugger to find the facts.
.El
.Pp
.Sh  MRI Compatible Script Files
To aid users making the transition to GNU
.Xr ld
from the MRI linker,
.Xr ld
can use MRI compatible linker scripts as an alternative to the more general-purpose
linker scripting language described in Scripts. MRI compatible linker scripts
have a much simpler command set than the scripting language otherwise used
with
.Xr ld .
GNU
.Xr ld
supports the most commonly used MRI linker commands; these commands are described
here.
.Pp
In general, MRI scripts aren't of much use with the
.Li a.out
object file format, since it only has three sections and MRI scripts lack
some features to make use of them.
.Pp
You can specify a file containing an MRI-compatible script using the
.Li -c
command-line option.
.Pp
Each command in an MRI-compatible script occupies its own line; each command
line starts with the keyword that identifies the command (though blank lines
are also allowed for punctuation). If a line of an MRI-compatible script begins
with an unrecognized keyword,
.Xr ld
issues a warning message, but continues processing the script.
.Pp
Lines beginning with
.Li *
are comments.
.Pp
You can write these commands using all upper-case letters, or all lower case;
for example,
.Li chip
is the same as
.Li CHIP .
The following list shows only the upper-case form of each command.
.Pp
.Bl -tag -width Ds
.It  ABSOLUTE Va secname
.It  ABSOLUTE Va secname, Va secname, ... Va secname
Normally,
.Xr ld
includes in the output file all sections from all the input files. However,
in an MRI-compatible script, you can use the
.Li ABSOLUTE
command to restrict the sections that will be present in your output program.
If the
.Li ABSOLUTE
command is used at all in a script, then only the sections named explicitly
in
.Li ABSOLUTE
commands will appear in the linker output. You can still use other input sections
(whatever you select on the command line, or using
.Li LOAD )
to resolve addresses in the output file.
.Pp
.It  ALIAS Va out-secname, Va in-secname
Use this command to place the data from input section
.Va in-secname
in a section called
.Va out-secname
in the linker output file.
.Pp
.Va in-secname
may be an integer.
.Pp
.It  ALIGN Va secname = Va expression
Align the section called
.Va secname
to
.Va expression .
The
.Va expression
should be a power of two.
.Pp
.It  BASE Va expression
Use the value of
.Va expression
as the lowest address (other than absolute addresses) in the output file.
.Pp
.It  CHIP Va expression
.It  CHIP Va expression, Va expression
This command does nothing; it is accepted only for compatibility.
.Pp
.It  END
This command does nothing whatever; it's only accepted for compatibility.
.Pp
.It  FORMAT Va output-format
Similar to the
.Li OUTPUT_FORMAT
command in the more general linker language, but restricted to one of these
output formats:
.Pp
.Bl -enum
.It
S-records, if
.Va output-format
is
.Li S
.Pp
.It
IEEE, if
.Va output-format
is
.Li IEEE
.Pp
.It
COFF (the
.Li coff-m68k
variant in BFD), if
.Va output-format
is
.Li COFF
.El
.Pp
.It  LIST Va anything...
Print (to the standard output file) a link map, as produced by the
.Xr ld
command-line option
.Li -M .
.Pp
The keyword
.Li LIST
may be followed by anything on the same line, with no change in its effect.
.Pp
.It  LOAD Va filename
.It  LOAD Va filename, Va filename, ... Va filename
Include one or more object file
.Va filename
in the link; this has the same effect as specifying
.Va filename
directly on the
.Xr ld
command line.
.Pp
.It  NAME Va output-name
.Va output-name
is the name for the program produced by
.Xr ld ;
the MRI-compatible command
.Li NAME
is equivalent to the command-line option
.Li -o
or the general script language command
.Li OUTPUT .
.Pp
.It  ORDER Va secname, Va secname, ... Va secname
.It  ORDER Va secname Va secname Va secname
Normally,
.Xr ld
orders the sections in its output file in the order in which they first appear
in the input files. In an MRI-compatible script, you can override this ordering
with the
.Li ORDER
command. The sections you list with
.Li ORDER
will appear first in your output file, in the order specified.
.Pp
.It  PUBLIC Va name= Va expression
.It  PUBLIC Va name, Va expression
.It  PUBLIC Va name Va expression
Supply a value (
.Va expression )
for external symbol
.Va name
used in the linker input files.
.Pp
.It  SECT Va secname, Va expression
.It  SECT Va secname= Va expression
.It  SECT Va secname Va expression
You can use any of these three forms of the
.Li SECT
command to specify the start address (
.Va expression )
for section
.Va secname .
If you have more than one
.Li SECT
statement for the same
.Va secname ,
only the
.Em first
sets the start address.
.El
.Pp
.Sh  GNU Free Documentation License
.Bd -filled -offset indent
Copyright (C) 2000, 2003 Free Software Foundation, Inc. 51 Franklin Street,
Fifth Floor, Boston, MA 02110-1301 USA
.Pp
Everyone is permitted to copy and distribute verbatim copies of this license
document, but changing it is not allowed.
.Ed
.Pp
.Bl -enum
.It
PREAMBLE
.Pp
The purpose of this License is to make a manual, textbook, or other written
document \(lqfree\(rq in the sense of freedom: to assure everyone the effective freedom
to copy and redistribute it, with or without modifying it, either commercially
or noncommercially. Secondarily, this License preserves for the author and
publisher a way to get credit for their work, while not being considered responsible
for modifications made by others.
.Pp
This License is a kind of \(lqcopyleft\(rq, which means that derivative works of the
document must themselves be free in the same sense. It complements the GNU
General Public License, which is a copyleft license designed for free software.
.Pp
We have designed this License in order to use it for manuals for free software,
because free software needs free documentation: a free program should come
with manuals providing the same freedoms that the software does. But this
License is not limited to software manuals; it can be used for any textual
work, regardless of subject matter or whether it is published as a printed
book. We recommend this License principally for works whose purpose is instruction
or reference.
.Pp
.It
APPLICABILITY AND DEFINITIONS
.Pp
This License applies to any manual or other work that contains a notice placed
by the copyright holder saying it can be distributed under the terms of this
License. The \(lqDocument\(rq, below, refers to any such manual or work. Any member
of the public is a licensee, and is addressed as \(lqyou.\(rq
.Pp
A \(lqModified Version\(rq of the Document means any work containing the Document
or a portion of it, either copied verbatim, or with modifications and/or translated
into another language.
.Pp
A \(lqSecondary Section\(rq is a named appendix or a front-matter section of the Document
that deals exclusively with the relationship of the publishers or authors
of the Document to the Document's overall subject (or to related matters)
and contains nothing that could fall directly within that overall subject.
(For example, if the Document is in part a textbook of mathematics, a Secondary
Section may not explain any mathematics.) The relationship could be a matter
of historical connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding them.
.Pp
The \(lqInvariant Sections\(rq are certain Secondary Sections whose titles are designated,
as being those of Invariant Sections, in the notice that says that the Document
is released under this License.
.Pp
The \(lqCover Texts\(rq are certain short passages of text that are listed, as Front-Cover
Texts or Back-Cover Texts, in the notice that says that the Document is released
under this License.
.Pp
A \(lqTransparent\(rq copy of the Document means a machine-readable copy, represented
in a format whose specification is available to the general public, whose
contents can be viewed and edited directly and straightforwardly with generic
text editors or (for images composed of pixels) generic paint programs or
(for drawings) some widely available drawing editor, and that is suitable
for input to text formatters or for automatic translation to a variety of
formats suitable for input to text formatters. A copy made in an otherwise
Transparent file format whose markup has been designed to thwart or discourage
subsequent modification by readers is not Transparent. A copy that is not
\(lqTransparent\(rq is called \(lqOpaque.\(rq
.Pp
Examples of suitable formats for Transparent copies include plain ASCII without
markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly
available DTD, and standard-conforming simple HTML designed for human modification.
Opaque formats include PostScript, PDF, proprietary formats that can be read
and edited only by proprietary word processors, SGML or XML for which the
DTD and/or processing tools are not generally available, and the machine-generated
HTML produced by some word processors for output purposes only.
.Pp
The \(lqTitle Page\(rq means, for a printed book, the title page itself, plus such
following pages as are needed to hold, legibly, the material this License
requires to appear in the title page. For works in formats which do not have
any title page as such, \(lqTitle Page\(rq means the text near the most prominent
appearance of the work's title, preceding the beginning of the body of the
text.
.Pp
.It
VERBATIM COPYING
.Pp
You may copy and distribute the Document in any medium, either commercially
or noncommercially, provided that this License, the copyright notices, and
the license notice saying this License applies to the Document are reproduced
in all copies, and that you add no other conditions whatsoever to those of
this License. You may not use technical measures to obstruct or control the
reading or further copying of the copies you make or distribute. However,
you may accept compensation in exchange for copies. If you distribute a large
enough number of copies you must also follow the conditions in section 3.
.Pp
You may also lend copies, under the same conditions stated above, and you
may publicly display copies.
.Pp
.It
COPYING IN QUANTITY
.Pp
If you publish printed copies of the Document numbering more than 100, and
the Document's license notice requires Cover Texts, you must enclose the copies
in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover
Texts on the front cover, and Back-Cover Texts on the back cover. Both covers
must also clearly and legibly identify you as the publisher of these copies.
The front cover must present the full title with all words of the title equally
prominent and visible. You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve the title
of the Document and satisfy these conditions, can be treated as verbatim copying
in other respects.
.Pp
If the required texts for either cover are too voluminous to fit legibly,
you should put the first ones listed (as many as fit reasonably) on the actual
cover, and continue the rest onto adjacent pages.
.Pp
If you publish or distribute Opaque copies of the Document numbering more
than 100, you must either include a machine-readable Transparent copy along
with each Opaque copy, or state in or with each Opaque copy a publicly-accessible
computer-network location containing a complete Transparent copy of the Document,
free of added material, which the general network-using public has access
to download anonymously at no charge using public-standard network protocols.
If you use the latter option, you must take reasonably prudent steps, when
you begin distribution of Opaque copies in quantity, to ensure that this Transparent
copy will remain thus accessible at the stated location until at least one
year after the last time you distribute an Opaque copy (directly or through
your agents or retailers) of that edition to the public.
.Pp
It is requested, but not required, that you contact the authors of the Document
well before redistributing any large number of copies, to give them a chance
to provide you with an updated version of the Document.
.Pp
.It
MODIFICATIONS
.Pp
You may copy and distribute a Modified Version of the Document under the conditions
of sections 2 and 3 above, provided that you release the Modified Version
under precisely this License, with the Modified Version filling the role of
the Document, thus licensing distribution and modification of the Modified
Version to whoever possesses a copy of it. In addition, you must do these
things in the Modified Version:
.Pp
A. Use in the Title Page (and on the covers, if any) a title distinct from
that of the Document, and from those of previous versions (which should, if
there were any, be listed in the History section of the Document). You may
use the same title as a previous version if the original publisher of that
version gives permission.  B. List on the Title Page, as authors, one or more
persons or entities responsible for authorship of the modifications in the
Modified Version, together with at least five of the principal authors of
the Document (all of its principal authors, if it has less than five).  C.
State on the Title page the name of the publisher of the Modified Version,
as the publisher.  D. Preserve all the copyright notices of the Document. 
E. Add an appropriate copyright notice for your modifications adjacent to
the other copyright notices.  F. Include, immediately after the copyright
notices, a license notice giving the public permission to use the Modified
Version under the terms of this License, in the form shown in the Addendum
below.  G. Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.  H. Include
an unaltered copy of this License.  I. Preserve the section entitled \(lqHistory\(rq,
and its title, and add to it an item stating at least the title, year, new
authors, and publisher of the Modified Version as given on the Title Page.
If there is no section entitled \(lqHistory\(rq in the Document, create one stating
the title, year, authors, and publisher of the Document as given on its Title
Page, then add an item describing the Modified Version as stated in the previous
sentence.  J. Preserve the network location, if any, given in the Document
for public access to a Transparent copy of the Document, and likewise the
network locations given in the Document for previous versions it was based
on. These may be placed in the \(lqHistory\(rq section. You may omit a network location
for a work that was published at least four years before the Document itself,
or if the original publisher of the version it refers to gives permission. 
K. In any section entitled \(lqAcknowledgements\(rq or \(lqDedications\(rq, preserve the section's
title, and preserve in the section all the substance and tone of each of the
contributor acknowledgements and/or dedications given therein.  L. Preserve
all the Invariant Sections of the Document, unaltered in their text and in
their titles. Section numbers or the equivalent are not considered part of
the section titles.  M. Delete any section entitled \(lqEndorsements.\(rq Such a section
may not be included in the Modified Version.  N. Do not retitle any existing
section as \(lqEndorsements\(rq or to conflict in title with any Invariant Section. 
.Pp
If the Modified Version includes new front-matter sections or appendices that
qualify as Secondary Sections and contain no material copied from the Document,
you may at your option designate some or all of these sections as invariant.
To do this, add their titles to the list of Invariant Sections in the Modified
Version's license notice. These titles must be distinct from any other section
titles.
.Pp
You may add a section entitled \(lqEndorsements\(rq, provided it contains nothing
but endorsements of your Modified Version by various parties--for example,
statements of peer review or that the text has been approved by an organization
as the authoritative definition of a standard.
.Pp
You may add a passage of up to five words as a Front-Cover Text, and a passage
of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts
in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover
Text may be added by (or through arrangements made by) any one entity. If
the Document already includes a cover text for the same cover, previously
added by you or by arrangement made by the same entity you are acting on behalf
of, you may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.
.Pp
The author(s) and publisher(s) of the Document do not by this License give
permission to use their names for publicity for or to assert or imply endorsement
of any Modified Version.
.Pp
.It
COMBINING DOCUMENTS
.Pp
You may combine the Document with other documents released under this License,
under the terms defined in section 4 above for modified versions, provided
that you include in the combination all of the Invariant Sections of all of
the original documents, unmodified, and list them all as Invariant Sections
of your combined work in its license notice.
.Pp
The combined work need only contain one copy of this License, and multiple
identical Invariant Sections may be replaced with a single copy. If there
are multiple Invariant Sections with the same name but different contents,
make the title of each such section unique by adding at the end of it, in
parentheses, the name of the original author or publisher of that section
if known, or else a unique number. Make the same adjustment to the section
titles in the list of Invariant Sections in the license notice of the combined
work.
.Pp
In the combination, you must combine any sections entitled \(lqHistory\(rq in the
various original documents, forming one section entitled \(lqHistory\(rq; likewise
combine any sections entitled \(lqAcknowledgements\(rq, and any sections entitled
\(lqDedications.\(rq You must delete all sections entitled \(lqEndorsements.\(rq
.Pp
.It
COLLECTIONS OF DOCUMENTS
.Pp
You may make a collection consisting of the Document and other documents released
under this License, and replace the individual copies of this License in the
various documents with a single copy that is included in the collection, provided
that you follow the rules of this License for verbatim copying of each of
the documents in all other respects.
.Pp
You may extract a single document from such a collection, and distribute it
individually under this License, provided you insert a copy of this License
into the extracted document, and follow this License in all other respects
regarding verbatim copying of that document.
.Pp
.It
AGGREGATION WITH INDEPENDENT WORKS
.Pp
A compilation of the Document or its derivatives with other separate and independent
documents or works, in or on a volume of a storage or distribution medium,
does not as a whole count as a Modified Version of the Document, provided
no compilation copyright is claimed for the compilation. Such a compilation
is called an \(lqaggregate\(rq, and this License does not apply to the other self-contained
works thus compiled with the Document, on account of their being thus compiled,
if they are not themselves derivative works of the Document.
.Pp
If the Cover Text requirement of section 3 is applicable to these copies of
the Document, then if the Document is less than one quarter of the entire
aggregate, the Document's Cover Texts may be placed on covers that surround
only the Document within the aggregate. Otherwise they must appear on covers
around the whole aggregate.
.Pp
.It
TRANSLATION
.Pp
Translation is considered a kind of modification, so you may distribute translations
of the Document under the terms of section 4. Replacing Invariant Sections
with translations requires special permission from their copyright holders,
but you may include translations of some or all Invariant Sections in addition
to the original versions of these Invariant Sections. You may include a translation
of this License provided that you also include the original English version
of this License. In case of a disagreement between the translation and the
original English version of this License, the original English version will
prevail.
.Pp
.It
TERMINATION
.Pp
You may not copy, modify, sublicense, or distribute the Document except as
expressly provided for under this License. Any other attempt to copy, modify,
sublicense or distribute the Document is void, and will automatically terminate
your rights under this License. However, parties who have received copies,
or rights, from you under this License will not have their licenses terminated
so long as such parties remain in full compliance.
.Pp
.It
FUTURE REVISIONS OF THIS LICENSE
.Pp
The Free Software Foundation may publish new, revised versions of the GNU
Free Documentation License from time to time. Such new versions will be similar
in spirit to the present version, but may differ in detail to address new
problems or concerns. See http://www.gnu.org/copyleft/.
.Pp
Each version of the License is given a distinguishing version number. If the
Document specifies that a particular numbered version of this License \(lqor any
later version\(rq applies to it, you have the option of following the terms and
conditions either of that specified version or of any later version that has
been published (not as a draft) by the Free Software Foundation. If the Document
does not specify a version number of this License, you may choose any version
ever published (not as a draft) by the Free Software Foundation.
.Pp
.El
.Ss  ADDENDUM: How to use this License for your documents
To use this License in a document you have written, include a copy of the
License in the document and put the following copyright and license notices
just after the title page:
.Pp
.Bd -literal -offset indent

Copyright (C)  year  your name.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with the Invariant Sections being list their titles, with the
Front-Cover Texts being list, and with the Back-Cover Texts being list.
A copy of the license is included in the section entitled "GNU
Free Documentation License."

.Ed
.Pp
If you have no Invariant Sections, write \(lqwith no Invariant Sections\(rq instead
of saying which ones are invariant. If you have no Front-Cover Texts, write
\(lqno Front-Cover Texts\(rq instead of \(lqFront-Cover Texts being
.Va list
\(rq; likewise for Back-Cover Texts.
.Pp
If your document contains nontrivial examples of program code, we recommend
releasing these examples in parallel under your choice of free software license,
such as the GNU General Public License, to permit their use in free software.
.Pp
.Sh  LD Index