1147 lines
47 KiB
Plaintext
1147 lines
47 KiB
Plaintext
This is Info file ld.info, produced by Makeinfo-1.64 from the input
|
||
file ./ld.texinfo.
|
||
|
||
START-INFO-DIR-ENTRY
|
||
* Ld: (ld). The GNU linker.
|
||
END-INFO-DIR-ENTRY
|
||
|
||
This file documents the GNU linker LD.
|
||
|
||
Copyright (C) 1991, 92, 93, 94, 95, 96, 1997 Free Software
|
||
Foundation, Inc.
|
||
|
||
Permission is granted to make and distribute verbatim copies of this
|
||
manual provided the copyright notice and this permission notice are
|
||
preserved on all copies.
|
||
|
||
Permission is granted to copy and distribute modified versions of
|
||
this manual under the conditions for verbatim copying, provided also
|
||
that the entire resulting derived work is distributed under the terms
|
||
of a permission notice identical to this one.
|
||
|
||
Permission is granted to copy and distribute translations of this
|
||
manual into another language, under the above conditions for modified
|
||
versions.
|
||
|
||
|
||
File: ld.info, Node: Top, Next: Overview, Up: (dir)
|
||
|
||
Using ld
|
||
********
|
||
|
||
This file documents the GNU linker ld.
|
||
|
||
* Menu:
|
||
|
||
* Overview:: Overview
|
||
* Invocation:: Invocation
|
||
* Commands:: Command Language
|
||
|
||
* Machine Dependent:: Machine Dependent Features
|
||
|
||
* BFD:: BFD
|
||
|
||
* Reporting Bugs:: Reporting Bugs
|
||
* MRI:: MRI Compatible Script Files
|
||
* Index:: Index
|
||
|
||
|
||
File: ld.info, Node: Overview, Next: Invocation, Prev: Top, Up: Top
|
||
|
||
Overview
|
||
********
|
||
|
||
`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 `ld'.
|
||
|
||
`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.
|
||
|
||
This version of `ld' uses the general purpose BFD libraries to
|
||
operate on object files. This allows `ld' to read, combine, and write
|
||
object files in many different formats--for example, COFF or `a.out'.
|
||
Different formats may be linked together to produce any available kind
|
||
of object file. *Note BFD::, for more information.
|
||
|
||
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,
|
||
`ld' continues executing, allowing you to identify other errors (or, in
|
||
some cases, to get an output file in spite of the error).
|
||
|
||
|
||
File: ld.info, Node: Invocation, Next: Commands, Prev: Overview, Up: Top
|
||
|
||
Invocation
|
||
**********
|
||
|
||
The GNU linker `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.
|
||
|
||
* Menu:
|
||
|
||
* Options:: Command Line Options
|
||
* Environment:: Environment Variables
|
||
|
||
|
||
File: ld.info, Node: Options, Next: Environment, Up: Invocation
|
||
|
||
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 `ld' is to link standard Unix object files on a
|
||
standard, supported Unix system. On such a system, to link a file
|
||
`hello.o':
|
||
|
||
ld -o OUTPUT /lib/crt0.o hello.o -lc
|
||
|
||
This tells `ld' to produce a file called OUTPUT as the result of
|
||
linking the file `/lib/crt0.o' with `hello.o' and the library `libc.a',
|
||
which will come from the standard search directories. (See the
|
||
discussion of the `-l' option below.)
|
||
|
||
The command-line options to `ld' may be specified in any order, and
|
||
may be repeated at will. Repeating most 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.
|
||
|
||
Non-option arguments are objects files 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.
|
||
|
||
Usually the linker is invoked with at least one object file, but you
|
||
can specify other forms of binary input files using `-l', `-R', and the
|
||
script command language. If *no* binary input files at all are
|
||
specified, the linker does not produce any output, and issues the
|
||
message `No input files'.
|
||
|
||
If the linker can not 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 `-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
|
||
`INPUT' or `GROUP' to load other objects. Note that specifying a
|
||
script in this way should only be used to augment the main linker
|
||
script; if you want to use some command that logically can only appear
|
||
once, such as the `SECTIONS' or `MEMORY' command, you must replace the
|
||
default linker script using the `-T' option. *Note Commands::.
|
||
|
||
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.
|
||
|
||
For options whose names are multiple letters, either one dash or two
|
||
can precede the option name; for example, `--oformat' and `--oformat'
|
||
are equivalent. 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, `--oformat srec' and `--oformat=srec' are equivalent.
|
||
Unique abbreviations of the names of multiple-letter options are
|
||
accepted.
|
||
|
||
`-aKEYWORD'
|
||
This option is supported for HP/UX compatibility. The KEYWORD
|
||
argument must be one of the strings `archive', `shared', or
|
||
`default'. `-aarchive' is functionally equivalent to `-Bstatic',
|
||
and the other two keywords are functionally equivalent to
|
||
`-Bdynamic'. This option may be used any number of times.
|
||
|
||
`-AARCHITECTURE'
|
||
`--architecture=ARCHITECTURE'
|
||
In the current release of `ld', this option is useful only for the
|
||
Intel 960 family of architectures. In that `ld' configuration, the
|
||
ARCHITECTURE argument identifies the particular architecture in
|
||
the 960 family, enabling some safeguards and modifying the
|
||
archive-library search path. *Note `ld' and the Intel 960 family:
|
||
i960, for details.
|
||
|
||
Future releases of `ld' may support similar functionality for
|
||
other architecture families.
|
||
|
||
`-b INPUT-FORMAT'
|
||
`--format=INPUT-FORMAT'
|
||
`ld' may be configured to support more than one kind of object
|
||
file. If your `ld' is configured this way, you can use the `-b'
|
||
option to specify the binary format for input object files that
|
||
follow this option on the command line. Even when `ld' is
|
||
configured to support alternative object formats, you don't
|
||
usually need to specify this, as `ld' should be configured to
|
||
expect as a default input format the most usual format on each
|
||
machine. 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 `objdump -i'.) *Note BFD::.
|
||
|
||
You may want to use this option if you are linking files with an
|
||
unusual binary format. You can also use `-b' to switch formats
|
||
explicitly (when linking object files of different formats), by
|
||
including `-b INPUT-FORMAT' before each group of object files in a
|
||
particular format.
|
||
|
||
The default format is taken from the environment variable
|
||
`GNUTARGET'. *Note Environment::. You can also define the input
|
||
format from a script, using the command `TARGET'; see *Note Option
|
||
Commands::.
|
||
|
||
`-c MRI-COMMANDFILE'
|
||
`--mri-script=MRI-COMMANDFILE'
|
||
For compatibility with linkers produced by MRI, `ld' accepts script
|
||
files written in an alternate, restricted command language,
|
||
described in *Note MRI Compatible Script Files: MRI. Introduce
|
||
MRI script files with the option `-c'; use the `-T' option to run
|
||
linker scripts written in the general-purpose `ld' scripting
|
||
language. If MRI-CMDFILE does not exist, `ld' looks for it in the
|
||
directories specified by any `-L' options.
|
||
|
||
`-d'
|
||
`-dc'
|
||
`-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
|
||
`-r'). The script command `FORCE_COMMON_ALLOCATION' has the same
|
||
effect. *Note Option Commands::.
|
||
|
||
`-e ENTRY'
|
||
`--entry=ENTRY'
|
||
Use ENTRY as the explicit symbol for beginning execution of your
|
||
program, rather than the default entry point. *Note Entry Point::,
|
||
for a discussion of defaults and other ways of specifying the
|
||
entry point.
|
||
|
||
`-E'
|
||
`--export-dynamic'
|
||
When creating a dynamically linked executable, add all symbols to
|
||
the dynamic symbol table. Normally, the dynamic symbol table
|
||
contains only symbols which are used by a dynamic object. This
|
||
option is needed for some uses of `dlopen'.
|
||
|
||
`-f'
|
||
`--auxiliary 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 NAME.
|
||
|
||
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 NAME. If there is one, it will be used instead of
|
||
the definition in the filter object. The shared object NAME need
|
||
not exist. Thus the shared object NAME may be used to provide an
|
||
alternative implementation of certain functions, perhaps for
|
||
debugging or for machine specific performance.
|
||
|
||
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.
|
||
|
||
`-F NAME'
|
||
`--filter 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 NAME.
|
||
|
||
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 NAME. Thus the
|
||
filter object can be used to select a subset of the symbols
|
||
provided by the object NAME.
|
||
|
||
Some older linkers used the `-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 `-b', `--format', `--oformat' options, the `TARGET'
|
||
command in linker scripts, and the `GNUTARGET' environment
|
||
variable. The GNU linker will ignore the `-F' option when not
|
||
creating an ELF shared object.
|
||
|
||
`--force-exe-suffix'
|
||
Make sure that an output file has a .exe suffix.
|
||
|
||
If a successfully built fully linked output file does not have a
|
||
`.exe' or `.dll' suffix, this option forces the linker to copy the
|
||
output file to one of the same name with a `.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 `.exe' suffix.
|
||
|
||
`-g'
|
||
Ignored. Provided for compatibility with other tools.
|
||
|
||
`-GVALUE'
|
||
`--gpsize=VALUE'
|
||
Set the maximum size of objects to be optimized using the GP
|
||
register to 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.
|
||
|
||
`-hNAME'
|
||
`-soname=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.
|
||
|
||
`-i'
|
||
Perform an incremental link (same as option `-r').
|
||
|
||
`-lARCHIVE'
|
||
`--library=ARCHIVE'
|
||
Add archive file ARCHIVE to the list of files to link. This
|
||
option may be used any number of times. `ld' will search its
|
||
path-list for occurrences of `libARCHIVE.a' for every ARCHIVE
|
||
specified.
|
||
|
||
On systems which support shared libraries, `ld' may also search for
|
||
libraries with extensions other than `.a'. Specifically, on ELF
|
||
and SunOS systems, `ld' will search a directory for a library with
|
||
an extension of `.so' before searching for one with an extension of
|
||
`.a'. By convention, a `.so' extension indicates a shared library.
|
||
|
||
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.
|
||
|
||
See the `-(' option for a way to force the linker to search
|
||
archives multiple times.
|
||
|
||
You may list the same archive multiple times on the command line.
|
||
|
||
This type of archive searching is standard for Unix linkers.
|
||
However, if you are using `ld' on AIX, note that it is different
|
||
from the behaviour of the AIX linker.
|
||
|
||
`-LSEARCHDIR'
|
||
`--library-path=SEARCHDIR'
|
||
Add path SEARCHDIR to the list of paths that `ld' will search for
|
||
archive libraries and `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 `-L' options apply to all `-l' options,
|
||
regardless of the order in which the options appear.
|
||
|
||
The default set of paths searched (without being specified with
|
||
`-L') depends on which emulation mode `ld' is using, and in some
|
||
cases also on how it was configured. *Note Environment::.
|
||
|
||
The paths can also be specified in a link script with the
|
||
`SEARCH_DIR' command. Directories specified this way are searched
|
||
at the point in which the linker script appears in the command
|
||
line.
|
||
|
||
`-mEMULATION'
|
||
Emulate the EMULATION linker. You can list the available
|
||
emulations with the `--verbose' or `-V' options. The default
|
||
depends on how your `ld' was configured.
|
||
|
||
`-M'
|
||
`--print-map'
|
||
Print (to the standard output) a link map--diagnostic information
|
||
about where symbols are mapped by `ld', and information on global
|
||
common storage allocation.
|
||
|
||
`-n'
|
||
`--nmagic'
|
||
Set the text segment to be read only, and mark the output as
|
||
`NMAGIC' if possible.
|
||
|
||
`-N'
|
||
`--omagic'
|
||
Set the text and data sections to be readable and writable. Also,
|
||
do not page-align the data segment. If the output format supports
|
||
Unix style magic numbers, mark the output as `OMAGIC'.
|
||
|
||
`-o OUTPUT'
|
||
`--output=OUTPUT'
|
||
Use OUTPUT as the name for the program produced by `ld'; if this
|
||
option is not specified, the name `a.out' is used by default. The
|
||
script command `OUTPUT' can also specify the output file name.
|
||
|
||
`-r'
|
||
`--relocateable'
|
||
Generate relocatable output--i.e., generate an output file that
|
||
can in turn serve as input to `ld'. This is often called "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 `OMAGIC'. If this option is not specified, an absolute
|
||
file is produced. When linking C++ programs, this option *will
|
||
not* resolve references to constructors; to do that, use `-Ur'.
|
||
|
||
This option does the same thing as `-i'.
|
||
|
||
`-R FILENAME'
|
||
`--just-symbols=FILENAME'
|
||
Read symbol names and their addresses from 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.
|
||
|
||
For compatibility with other ELF linkers, if the `-R' option is
|
||
followed by a directory name, rather than a file name, it is
|
||
treated as the `-rpath' option.
|
||
|
||
`-s'
|
||
`--strip-all'
|
||
Omit all symbol information from the output file.
|
||
|
||
`-S'
|
||
`--strip-debug'
|
||
Omit debugger symbol information (but not all symbols) from the
|
||
output file.
|
||
|
||
`-t'
|
||
`--trace'
|
||
Print the names of the input files as `ld' processes them.
|
||
|
||
`-T COMMANDFILE'
|
||
`--script=COMMANDFILE'
|
||
Read link commands from the file COMMANDFILE. These commands
|
||
replace `ld''s default link script (rather than adding to it), so
|
||
COMMANDFILE must specify everything necessary to describe the
|
||
target format. You must use this option if you want to use a
|
||
command which can only appear once in a linker script, such as the
|
||
`SECTIONS' or `MEMORY' command. *Note Commands::. If COMMANDFILE
|
||
does not exist, `ld' looks for it in the directories specified by
|
||
any preceding `-L' options. Multiple `-T' options accumulate.
|
||
|
||
`-u SYMBOL'
|
||
`--undefined=SYMBOL'
|
||
Force 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. `-u' may be repeated
|
||
with different option arguments to enter additional undefined
|
||
symbols.
|
||
|
||
`-v'
|
||
`--version'
|
||
`-V'
|
||
Display the version number for `ld'. The `-V' option also lists
|
||
the supported emulations.
|
||
|
||
`-x'
|
||
`--discard-all'
|
||
Delete all local symbols.
|
||
|
||
`-X'
|
||
`--discard-locals'
|
||
Delete all temporary local symbols. For most targets, this is all
|
||
local symbols whose names begin with `L'.
|
||
|
||
`-y SYMBOL'
|
||
`--trace-symbol=SYMBOL'
|
||
Print the name of each linked file in which SYMBOL appears. This
|
||
option may be given any number of times. On many systems it is
|
||
necessary to prepend an underscore.
|
||
|
||
This option is useful when you have an undefined symbol in your
|
||
link but don't know where the reference is coming from.
|
||
|
||
`-Y PATH'
|
||
Add PATH to the default library search path. This option exists
|
||
for Solaris compatibility.
|
||
|
||
`-z KEYWORD'
|
||
This option is ignored for Solaris compatibility.
|
||
|
||
`-( ARCHIVES -)'
|
||
`--start-group ARCHIVES --end-group'
|
||
The ARCHIVES should be a list of archive files. They may be
|
||
either explicit file names, or `-l' options.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
`-assert KEYWORD'
|
||
This option is ignored for SunOS compatibility.
|
||
|
||
`-Bdynamic'
|
||
`-dy'
|
||
`-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 `-l' options which follow it.
|
||
|
||
`-Bstatic'
|
||
`-dn'
|
||
`-non_shared'
|
||
`-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 `-l' options which follow
|
||
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.
|
||
|
||
`--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.
|
||
|
||
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.
|
||
|
||
`--defsym SYMBOL=EXPRESSION'
|
||
Create a global symbol in the output file, containing the absolute
|
||
address given by 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 EXPRESSION in
|
||
this context: you may give a hexadecimal constant or the name of
|
||
an existing symbol, or use `+' and `-' to add or subtract
|
||
hexadecimal constants or symbols. If you need more elaborate
|
||
expressions, consider using the linker command language from a
|
||
script (*note Assignment: Symbol Definitions: Assignment.).
|
||
*Note:* there should be no white space between SYMBOL, the equals
|
||
sign ("="), and EXPRESSION.
|
||
|
||
`--dynamic-linker 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.
|
||
|
||
`-EB'
|
||
Link big-endian objects. This affects the default output format.
|
||
|
||
`-EL'
|
||
Link little-endian objects. This affects the default output
|
||
format.
|
||
|
||
`--embedded-relocs'
|
||
This option is only meaningful when linking MIPS embedded PIC code,
|
||
generated by the -membedded-pic option to the GNU compiler and
|
||
assembler. It causes the linker to create a table which may be
|
||
used at runtime to relocate any data which was statically
|
||
initialized to pointer values. See the code in testsuite/ld-empic
|
||
for details.
|
||
|
||
`--help'
|
||
Print a summary of the command-line options on the standard output
|
||
and exit.
|
||
|
||
`-Map MAPFILE'
|
||
Print to the file MAPFILE a link map--diagnostic information about
|
||
where symbols are mapped by `ld', and information on global common
|
||
storage allocation.
|
||
|
||
`--no-keep-memory'
|
||
`ld' normally optimizes for speed over memory usage by caching the
|
||
symbol tables of input files in memory. This option tells `ld' to
|
||
instead optimize for memory usage, by rereading the symbol tables
|
||
as necessary. This may be required if `ld' runs out of memory
|
||
space while linking a large executable.
|
||
|
||
`--no-whole-archive'
|
||
Turn off the effect of the `--whole-archive' option for subsequent
|
||
archive files.
|
||
|
||
`--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.
|
||
|
||
`--oformat OUTPUT-FORMAT'
|
||
`ld' may be configured to support more than one kind of object
|
||
file. If your `ld' is configured this way, you can use the
|
||
`--oformat' option to specify the binary format for the output
|
||
object file. Even when `ld' is configured to support alternative
|
||
object formats, you don't usually need to specify this, as `ld'
|
||
should be configured to produce as a default output format the most
|
||
usual format on each machine. 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 `objdump -i'.) The
|
||
script command `OUTPUT_FORMAT' can also specify the output format,
|
||
but this option overrides it. *Note BFD::.
|
||
|
||
`-qmagic'
|
||
This option is ignored for Linux compatibility.
|
||
|
||
`-Qy'
|
||
This option is ignored for SVR4 compatibility.
|
||
|
||
`--relax'
|
||
An option with machine dependent effects. This option is only
|
||
supported on a few targets. *Note `ld' and the H8/300: H8/300.
|
||
*Note `ld' and the Intel 960 family: i960.
|
||
|
||
On some platforms, the `--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.
|
||
|
||
On platforms where this is not supported, `--relax' is accepted,
|
||
but ignored.
|
||
|
||
`--retain-symbols-file FILENAME'
|
||
Retain *only* the symbols listed in the file FILENAME, discarding
|
||
all others. 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.
|
||
|
||
`--retain-symbols-file' does *not* discard undefined symbols, or
|
||
symbols needed for relocations.
|
||
|
||
You may only specify `--retain-symbols-file' once in the command
|
||
line. It overrides `-s' and `-S'.
|
||
|
||
`-rpath DIR'
|
||
Add a directory to the runtime library search path. This is used
|
||
when linking an ELF executable with shared objects. All `-rpath'
|
||
arguments are concatenated and passed to the runtime linker, which
|
||
uses them to locate shared objects at runtime. The `-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 `-rpath-link' option. If `-rpath' is not used
|
||
when linking an ELF executable, the contents of the environment
|
||
variable `LD_RUN_PATH' will be used if it is defined.
|
||
|
||
The `-rpath' option may also be used on SunOS. By default, on
|
||
SunOS, the linker will form a runtime search patch out of all the
|
||
`-L' options it is given. If a `-rpath' option is used, the
|
||
runtime search path will be formed exclusively using the `-rpath'
|
||
options, ignoring the `-L' options. This can be useful when using
|
||
gcc, which adds many `-L' options which may be on NFS mounted
|
||
filesystems.
|
||
|
||
For compatibility with other ELF linkers, if the `-R' option is
|
||
followed by a directory name, rather than a file name, it is
|
||
treated as the `-rpath' option.
|
||
|
||
`-rpath-link DIR'
|
||
When using ELF or SunOS, one shared library may require another.
|
||
This happens when an `ld -shared' link includes a shared library
|
||
as one of the input files.
|
||
|
||
When the linker encounters such a dependency when doing a
|
||
non-shared, non-relocateable 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 `-rpath-link'
|
||
option specifies the first set of directories to search. The
|
||
`-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.
|
||
|
||
The linker uses the following search paths to locate required
|
||
shared libraries.
|
||
1. Any directories specified by `-rpath-link' options.
|
||
|
||
2. Any directories specified by `-rpath' options. The difference
|
||
between `-rpath' and `-rpath-link' is that directories
|
||
specified by `-rpath' options are included in the executable
|
||
and used at runtime, whereas the `-rpath-link' option is only
|
||
effective at link time.
|
||
|
||
3. On an ELF system, if the `-rpath' and `rpath-link' options
|
||
were not used, search the contents of the environment variable
|
||
`LD_RUN_PATH'.
|
||
|
||
4. On SunOS, if the `-rpath' option was not used, search any
|
||
directories specified using `-L' options.
|
||
|
||
5. For a native linker, the contents of the environment variable
|
||
`LD_LIBRARY_PATH'.
|
||
|
||
6. The default directories, normally `/lib' and `/usr/lib'.
|
||
|
||
If the required shared library is not found, the linker will issue
|
||
a warning and continue with the link.
|
||
|
||
`-shared'
|
||
`-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 `-e' option is not
|
||
used and there are undefined symbols in the link.
|
||
|
||
`--sort-common'
|
||
This option tells `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 bytes, then all the four
|
||
bytes, and then everything else. This is to prevent gaps between
|
||
symbols due to alignment constraints.
|
||
|
||
`--split-by-file'
|
||
Similar to `--split-by-reloc' but creates a new output section for
|
||
each input file.
|
||
|
||
`--split-by-reloc COUNT'
|
||
Trys to creates extra sections in the output file so that no single
|
||
output section in the file contains more than COUNT relocations.
|
||
This is useful when generating huge relocatable 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 COUNT relocations one
|
||
output section will contain that many relocations.
|
||
|
||
`--stats'
|
||
Compute and display statistics about the operation of the linker,
|
||
such as execution time and memory usage.
|
||
|
||
`--traditional-format'
|
||
For some targets, the output of `ld' is different in some ways from
|
||
the output of some existing linker. This switch requests `ld' to
|
||
use the traditional format instead.
|
||
|
||
For example, on SunOS, `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 `dbx' program can not read the resulting
|
||
program (`gdb' has no trouble). The `--traditional-format' switch
|
||
tells `ld' to not combine duplicate entries.
|
||
|
||
`-Tbss ORG'
|
||
`-Tdata ORG'
|
||
`-Ttext ORG'
|
||
Use ORG as the starting address for--respectively--the `bss',
|
||
`data', or the `text' segment of the output file. ORG must be a
|
||
single hexadecimal integer; for compatibility with other linkers,
|
||
you may omit the leading `0x' usually associated with hexadecimal
|
||
values.
|
||
|
||
`-Ur'
|
||
For anything other than C++ programs, this option is equivalent to
|
||
`-r': it generates relocatable output--i.e., an output file that
|
||
can in turn serve as input to `ld'. When linking C++ programs,
|
||
`-Ur' *does* resolve references to constructors, unlike `-r'. It
|
||
does not work to use `-Ur' on files that were themselves linked
|
||
with `-Ur'; once the constructor table has been built, it cannot
|
||
be added to. Use `-Ur' only for the last partial link, and `-r'
|
||
for the others.
|
||
|
||
`--verbose'
|
||
Display the version number for `ld' and list the linker emulations
|
||
supported. Display which input files can and cannot be opened.
|
||
Display the linker script if using a default builtin script.
|
||
|
||
`--version-script=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 heirarchy for the library
|
||
being created. This option is only meaningful on ELF platforms
|
||
which support shared libraries. *Note Version Script::.
|
||
|
||
`--warn-common'
|
||
Warn when a common symbol is combined with another common symbol
|
||
or with a symbol definition. Unix linkers allow this somewhat
|
||
sloppy practice, 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 practice, so you may get some warnings about symbols in the
|
||
libraries as well as in your programs.
|
||
|
||
There are three kinds of global symbols, illustrated here by C
|
||
examples:
|
||
|
||
`int i = 1;'
|
||
A definition, which goes in the initialized data section of
|
||
the output file.
|
||
|
||
`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.
|
||
|
||
`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.
|
||
|
||
The `--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.
|
||
|
||
1. Turning a common symbol into a reference, because there is
|
||
already a definition for the symbol.
|
||
FILE(SECTION): warning: common of `SYMBOL'
|
||
overridden by definition
|
||
FILE(SECTION): warning: defined here
|
||
|
||
2. 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.
|
||
FILE(SECTION): warning: definition of `SYMBOL'
|
||
overriding common
|
||
FILE(SECTION): warning: common is here
|
||
|
||
3. Merging a common symbol with a previous same-sized common
|
||
symbol.
|
||
FILE(SECTION): warning: multiple common
|
||
of `SYMBOL'
|
||
FILE(SECTION): warning: previous common is here
|
||
|
||
4. Merging a common symbol with a previous larger common symbol.
|
||
FILE(SECTION): warning: common of `SYMBOL'
|
||
overridden by larger common
|
||
FILE(SECTION): warning: larger common is here
|
||
|
||
5. 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.
|
||
FILE(SECTION): warning: common of `SYMBOL'
|
||
overriding smaller common
|
||
FILE(SECTION): warning: smaller common is here
|
||
|
||
`--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.
|
||
|
||
`--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.
|
||
|
||
`--warn-once'
|
||
Only warn once for each undefined symbol, rather than once per
|
||
module which refers to 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 `SECTIONS' command does not specify a
|
||
start address for the section (*note SECTIONS::.).
|
||
|
||
`--whole-archive'
|
||
For each archive mentioned on the command line after the
|
||
`--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.
|
||
|
||
`--wrap SYMBOL'
|
||
Use a wrapper function for SYMBOL. Any undefined reference to
|
||
SYMBOL will be resolved to `__wrap_SYMBOL'. Any undefined
|
||
reference to `__real_SYMBOL' will be resolved to SYMBOL.
|
||
|
||
This can be used to provide a wrapper for a system function. The
|
||
wrapper function should be called `__wrap_SYMBOL'. If it wishes
|
||
to call the system function, it should call `__real_SYMBOL'.
|
||
|
||
Here is a trivial example:
|
||
|
||
void *
|
||
__wrap_malloc (int c)
|
||
{
|
||
printf ("malloc called with %ld\n", c);
|
||
return __real_malloc (c);
|
||
}
|
||
|
||
If you link other code with this file using `--wrap malloc', then
|
||
all calls to `malloc' will call the function `__wrap_malloc'
|
||
instead. The call to `__real_malloc' in `__wrap_malloc' will call
|
||
the real `malloc' function.
|
||
|
||
You may wish to provide a `__real_malloc' function as well, so that
|
||
links without the `--wrap' option will succeed. If you do this,
|
||
you should not put the definition of `__real_malloc' in the same
|
||
file as `__wrap_malloc'; if you do, the assembler may resolve the
|
||
call before the linker has a chance to wrap it to `malloc'.
|
||
|
||
|
||
File: ld.info, Node: Environment, Prev: Options, Up: Invocation
|
||
|
||
Environment Variables
|
||
=====================
|
||
|
||
You can change the behavior of `ld' with the environment variable
|
||
`GNUTARGET'.
|
||
|
||
`GNUTARGET' determines the input-file object format if you don't use
|
||
`-b' (or its synonym `--format'). Its value should be one of the BFD
|
||
names for an input format (*note BFD::.). If there is no `GNUTARGET'
|
||
in the environment, `ld' uses the natural format of the target. If
|
||
`GNUTARGET' is set to `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.
|
||
|
||
|
||
File: ld.info, Node: Commands, Next: Machine Dependent, Prev: Invocation, Up: Top
|
||
|
||
Command Language
|
||
****************
|
||
|
||
The command language provides explicit control over the link process,
|
||
allowing complete specification of the mapping between the linker's
|
||
input files and its output. It controls:
|
||
* input files
|
||
|
||
* file formats
|
||
|
||
* output file layout
|
||
|
||
* addresses of sections
|
||
|
||
* placement of common blocks
|
||
|
||
You may supply a command file (also known as a linker script) to the
|
||
linker either explicitly through the `-T' option, or implicitly as an
|
||
ordinary file. Normally you should use the `-T' option. An implicit
|
||
linker script should only be used when you want to augment, rather than
|
||
replace, the default linker script; typically an implicit linker script
|
||
would consist only of `INPUT' or `GROUP' commands.
|
||
|
||
If the linker opens a file which it cannot recognize as a supported
|
||
object or archive format, nor as a linker script, it reports an error.
|
||
|
||
* Menu:
|
||
|
||
* Scripts:: Linker Scripts
|
||
* Expressions:: Expressions
|
||
* MEMORY:: MEMORY Command
|
||
* SECTIONS:: SECTIONS Command
|
||
* PHDRS:: PHDRS Command
|
||
* Entry Point:: The Entry Point
|
||
* Version Script:: Version Script
|
||
* Option Commands:: Option Commands
|
||
|
||
|
||
File: ld.info, Node: Scripts, Next: Expressions, Up: Commands
|
||
|
||
Linker Scripts
|
||
==============
|
||
|
||
The `ld' command language is a collection of statements; some are
|
||
simple keywords setting a particular option, some are used to select and
|
||
group input files or name output files; and two statement types have a
|
||
fundamental and pervasive impact on the linking process.
|
||
|
||
The most fundamental command of the `ld' command language is the
|
||
`SECTIONS' command (*note SECTIONS::.). Every meaningful command
|
||
script must have a `SECTIONS' command: it specifies a "picture" of the
|
||
output file's layout, in varying degrees of detail. No other command
|
||
is required in all cases.
|
||
|
||
The `MEMORY' command complements `SECTIONS' by describing the
|
||
available memory in the target architecture. This command is optional;
|
||
if you don't use a `MEMORY' command, `ld' assumes sufficient memory is
|
||
available in a contiguous block for all output. *Note MEMORY::.
|
||
|
||
You may include comments in linker scripts just as in C: delimited
|
||
by `/*' and `*/'. As in C, comments are syntactically equivalent to
|
||
whitespace.
|
||
|
||
|
||
File: ld.info, Node: Expressions, Next: MEMORY, Prev: Scripts, Up: Commands
|
||
|
||
Expressions
|
||
===========
|
||
|
||
Many useful commands involve arithmetic expressions. The syntax for
|
||
expressions in the command language is identical to that of C
|
||
expressions, with the following features:
|
||
* All expressions evaluated as integers and are of "long" or
|
||
"unsigned long" type.
|
||
|
||
* All constants are integers.
|
||
|
||
* All of the C arithmetic operators are provided.
|
||
|
||
* You may reference, define, and create global variables.
|
||
|
||
* You may call special purpose built-in functions.
|
||
|
||
* Menu:
|
||
|
||
* Integers:: Integers
|
||
* Symbols:: Symbol Names
|
||
* Location Counter:: The Location Counter
|
||
* Operators:: Operators
|
||
* Evaluation:: Evaluation
|
||
* Assignment:: Assignment: Defining Symbols
|
||
* Arithmetic Functions:: Built-In Functions
|
||
* Semicolons:: Semicolon Usage
|
||
|
||
|
||
File: ld.info, Node: Integers, Next: Symbols, Up: Expressions
|
||
|
||
Integers
|
||
--------
|
||
|
||
An octal integer is `0' followed by zero or more of the octal digits
|
||
(`01234567').
|
||
_as_octal = 0157255;
|
||
|
||
A decimal integer starts with a non-zero digit followed by zero or
|
||
more digits (`0123456789').
|
||
_as_decimal = 57005;
|
||
|
||
A hexadecimal integer is `0x' or `0X' followed by one or more
|
||
hexadecimal digits chosen from `0123456789abcdefABCDEF'.
|
||
_as_hex = 0xdead;
|
||
|
||
To write a negative integer, use the prefix operator `-' (*note
|
||
Operators::.).
|
||
_as_neg = -57005;
|
||
|
||
Additionally the suffixes `K' and `M' may be used to scale a
|
||
constant by `1024' or `1024*1024' respectively. For example, the
|
||
following all refer to the same quantity:
|
||
|
||
_fourk_1 = 4K;
|
||
_fourk_2 = 4096;
|
||
_fourk_3 = 0x1000;
|
||
|
||
|
||
File: ld.info, Node: Symbols, Next: Location Counter, Prev: Integers, Up: Expressions
|
||
|
||
Symbol Names
|
||
------------
|
||
|
||
Unless quoted, symbol names start with a letter, underscore, or point
|
||
and may include any letters, underscores, digits, points, 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:
|
||
"SECTION" = 9;
|
||
"with a space" = "also with a space" + 10;
|
||
|
||
Since symbols can contain many non-alphabetic characters, it is
|
||
safest to delimit symbols with spaces. For example, `A-B' is one
|
||
symbol, whereas `A - B' is an expression involving subtraction.
|
||
|
||
|
||
File: ld.info, Node: Location Counter, Next: Operators, Prev: Symbols, Up: Expressions
|
||
|
||
The Location Counter
|
||
--------------------
|
||
|
||
The special linker variable "dot" `.' always contains the current
|
||
output location counter. Since the `.' always refers to a location in
|
||
an output section, it must always appear in an expression within a
|
||
`SECTIONS' command. The `.' symbol may appear anywhere that an ordinary
|
||
symbol is allowed in an expression, but its assignments have a side
|
||
effect. Assigning a value to the `.' symbol will cause the location
|
||
counter to be moved. This may be used to create holes in the output
|
||
section. The location counter may never be moved backwards.
|
||
SECTIONS
|
||
{
|
||
output :
|
||
{
|
||
file1(.text)
|
||
. = . + 1000;
|
||
file2(.text)
|
||
. += 1000;
|
||
file3(.text)
|
||
} = 0x1234;
|
||
}
|
||
|
||
In the previous example, `file1' is located at the beginning of the
|
||
output section, then there is a 1000 byte gap. Then `file2' appears,
|
||
also with a 1000 byte gap following before `file3' is loaded. The
|
||
notation `= 0x1234' specifies what data to write in the gaps (*note
|
||
Section Options::.).
|
||
|
||
|
||
File: ld.info, Node: Operators, Next: Evaluation, Prev: Location Counter, Up: Expressions
|
||
|
||
Operators
|
||
---------
|
||
|
||
The linker recognizes the standard C set of arithmetic operators,
|
||
with the standard bindings and precedence levels:
|
||
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)
|
||
Notes: (1) Prefix operators (2) *Note Assignment::.
|
||
|
||
|
||
File: ld.info, Node: Evaluation, Next: Assignment, Prev: Operators, Up: Expressions
|
||
|
||
Evaluation
|
||
----------
|
||
|
||
The linker uses "lazy evaluation" for expressions; it only calculates
|
||
an expression when absolutely necessary. The linker needs the value of
|
||
the start address, and the 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 command file. 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.
|
||
|