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