4819 lines
168 KiB
HTML
4819 lines
168 KiB
HTML
<HTML>
|
|
<HEAD>
|
|
<!-- This HTML file has been created by texi2html 1.52
|
|
from ../texi/ld.texinfo on 7 November 1998 -->
|
|
|
|
<TITLE>Using LD, the GNU linker</TITLE>
|
|
</HEAD>
|
|
<BODY>
|
|
<H1>Using ld</H1>
|
|
<H2>The GNU linker</H2>
|
|
<H2><CODE>ld</CODE> version 2</H2>
|
|
<H2>January 1994</H2>
|
|
<ADDRESS>Steve Chamberlain</ADDRESS>
|
|
<ADDRESS>Cygnus Support</ADDRESS>
|
|
<P>
|
|
<P><HR><P>
|
|
<H1>Table of Contents</H1>
|
|
<UL>
|
|
<LI><A NAME="TOC1" HREF="ld.html#SEC1">Overview</A>
|
|
<LI><A NAME="TOC2" HREF="ld.html#SEC2">Invocation</A>
|
|
<UL>
|
|
<LI><A NAME="TOC3" HREF="ld.html#SEC3">Command Line Options</A>
|
|
<LI><A NAME="TOC4" HREF="ld.html#SEC4">Environment Variables</A>
|
|
</UL>
|
|
<LI><A NAME="TOC5" HREF="ld.html#SEC5">Command Language</A>
|
|
<UL>
|
|
<LI><A NAME="TOC6" HREF="ld.html#SEC6">Linker Scripts</A>
|
|
<LI><A NAME="TOC7" HREF="ld.html#SEC7">Expressions</A>
|
|
<UL>
|
|
<LI><A NAME="TOC8" HREF="ld.html#SEC8">Integers</A>
|
|
<LI><A NAME="TOC9" HREF="ld.html#SEC9">Symbol Names</A>
|
|
<LI><A NAME="TOC10" HREF="ld.html#SEC10">The Location Counter</A>
|
|
<LI><A NAME="TOC11" HREF="ld.html#SEC11">Operators</A>
|
|
<LI><A NAME="TOC12" HREF="ld.html#SEC12">Evaluation</A>
|
|
<LI><A NAME="TOC13" HREF="ld.html#SEC13">Assignment: Defining Symbols</A>
|
|
<LI><A NAME="TOC14" HREF="ld.html#SEC14">Arithmetic Functions</A>
|
|
<LI><A NAME="TOC15" HREF="ld.html#SEC15">Semicolons</A>
|
|
</UL>
|
|
<LI><A NAME="TOC16" HREF="ld.html#SEC16">Memory Layout</A>
|
|
<LI><A NAME="TOC17" HREF="ld.html#SEC17">Specifying Output Sections</A>
|
|
<UL>
|
|
<LI><A NAME="TOC18" HREF="ld.html#SEC18">Section Definitions</A>
|
|
<LI><A NAME="TOC19" HREF="ld.html#SEC19">Section Placement</A>
|
|
<LI><A NAME="TOC20" HREF="ld.html#SEC20">Section Data Expressions</A>
|
|
<LI><A NAME="TOC21" HREF="ld.html#SEC21">Optional Section Attributes</A>
|
|
<LI><A NAME="TOC22" HREF="ld.html#SEC22">Overlays</A>
|
|
</UL>
|
|
<LI><A NAME="TOC23" HREF="ld.html#SEC23">ELF Program Headers</A>
|
|
<LI><A NAME="TOC24" HREF="ld.html#SEC24">The Entry Point</A>
|
|
<LI><A NAME="TOC25" HREF="ld.html#SEC25">Version Script</A>
|
|
<LI><A NAME="TOC26" HREF="ld.html#SEC26">Option Commands</A>
|
|
</UL>
|
|
<LI><A NAME="TOC27" HREF="ld.html#SEC27">Machine Dependent Features</A>
|
|
<UL>
|
|
<LI><A NAME="TOC28" HREF="ld.html#SEC28"><CODE>ld</CODE> and the H8/300</A>
|
|
<LI><A NAME="TOC29" HREF="ld.html#SEC29"><CODE>ld</CODE> and the Intel 960 family</A>
|
|
</UL>
|
|
<LI><A NAME="TOC30" HREF="ld.html#SEC30">BFD</A>
|
|
<UL>
|
|
<LI><A NAME="TOC31" HREF="ld.html#SEC31">How it works: an outline of BFD</A>
|
|
<UL>
|
|
<LI><A NAME="TOC32" HREF="ld.html#SEC32">Information Loss</A>
|
|
<LI><A NAME="TOC33" HREF="ld.html#SEC33">The BFD canonical object-file format</A>
|
|
</UL>
|
|
</UL>
|
|
<LI><A NAME="TOC34" HREF="ld.html#SEC34">Reporting Bugs</A>
|
|
<UL>
|
|
<LI><A NAME="TOC35" HREF="ld.html#SEC35">Have you found a bug?</A>
|
|
<LI><A NAME="TOC36" HREF="ld.html#SEC36">How to report bugs</A>
|
|
</UL>
|
|
<LI><A NAME="TOC37" HREF="ld.html#SEC37">MRI Compatible Script Files</A>
|
|
<LI><A NAME="TOC38" HREF="ld.html#SEC38">Index</A>
|
|
</UL>
|
|
<P><HR><P>
|
|
|
|
<P>
|
|
|
|
<P>
|
|
Copyright (C) 1991, 92, 93, 94, 95, 96, 97, 1998 Free Software Foundation, Inc.
|
|
|
|
</P>
|
|
<P>
|
|
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.
|
|
|
|
</P>
|
|
<P>
|
|
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.
|
|
|
|
</P>
|
|
<P>
|
|
Permission is granted to copy and distribute translations of this manual
|
|
into another language, under the above conditions for modified versions.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC1" HREF="ld.html#TOC1">Overview</A></H1>
|
|
|
|
<P>
|
|
<A NAME="IDX1"></A>
|
|
<A NAME="IDX2"></A>
|
|
<CODE>ld</CODE> 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 <CODE>ld</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
<CODE>ld</CODE> 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.
|
|
|
|
</P>
|
|
<P>
|
|
This version of <CODE>ld</CODE> uses the general purpose BFD libraries
|
|
to operate on object files. This allows <CODE>ld</CODE> to read, combine, and
|
|
write object files in many different formats--for example, COFF or
|
|
<CODE>a.out</CODE>. Different formats may be linked together to produce any
|
|
available kind of object file. See section <A HREF="ld.html#SEC30">BFD</A>, for more information.
|
|
|
|
</P>
|
|
<P>
|
|
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,
|
|
<CODE>ld</CODE> continues executing, allowing you to identify other errors
|
|
(or, in some cases, to get an output file in spite of the error).
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC2" HREF="ld.html#TOC2">Invocation</A></H1>
|
|
|
|
<P>
|
|
The GNU linker <CODE>ld</CODE> 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.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC3" HREF="ld.html#TOC3">Command Line Options</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX3"></A>
|
|
<A NAME="IDX4"></A>
|
|
The linker supports a plethora of command-line options, but in actual
|
|
practice few of them are used in any particular context.
|
|
<A NAME="IDX5"></A>
|
|
For instance, a frequent use of <CODE>ld</CODE> is to link standard Unix
|
|
object files on a standard, supported Unix system. On such a system, to
|
|
link a file <CODE>hello.o</CODE>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
ld -o <VAR>output</VAR> /lib/crt0.o hello.o -lc
|
|
</PRE>
|
|
|
|
<P>
|
|
This tells <CODE>ld</CODE> to produce a file called <VAR>output</VAR> as the
|
|
result of linking the file <CODE>/lib/crt0.o</CODE> with <CODE>hello.o</CODE> and
|
|
the library <CODE>libc.a</CODE>, which will come from the standard search
|
|
directories. (See the discussion of the <SAMP>`-l'</SAMP> option below.)
|
|
|
|
</P>
|
|
<P>
|
|
The command-line options to <CODE>ld</CODE> 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.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX6"></A>
|
|
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.
|
|
|
|
</P>
|
|
<P>
|
|
Usually the linker is invoked with at least one object file, but you can
|
|
specify other forms of binary input files using <SAMP>`-l'</SAMP>, <SAMP>`-R'</SAMP>,
|
|
and the script command language. If <EM>no</EM> binary input files at all
|
|
are specified, the linker does not produce any output, and issues the
|
|
message <SAMP>`No input files'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
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 <SAMP>`-T'</SAMP>). 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
|
|
<CODE>INPUT</CODE> or <CODE>GROUP</CODE> 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 <CODE>SECTIONS</CODE> or <CODE>MEMORY</CODE> command, you
|
|
must replace the default linker script using the <SAMP>`-T'</SAMP> option.
|
|
See section <A HREF="ld.html#SEC5">Command Language</A>.
|
|
|
|
</P>
|
|
<P>
|
|
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.
|
|
|
|
</P>
|
|
<P>
|
|
For options whose names are multiple letters, either one dash or two can
|
|
precede the option name; for example, <SAMP>`--oformat'</SAMP> and
|
|
<SAMP>`--oformat'</SAMP> 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, <SAMP>`--oformat srec'</SAMP> and
|
|
<SAMP>`--oformat=srec'</SAMP> are equivalent. Unique abbreviations of the names
|
|
of multiple-letter options are accepted.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>-a<VAR>keyword</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX7"></A>
|
|
|
|
This option is supported for HP/UX compatibility. The <VAR>keyword</VAR>
|
|
argument must be one of the strings <SAMP>`archive'</SAMP>, <SAMP>`shared'</SAMP>, or
|
|
<SAMP>`default'</SAMP>. <SAMP>`-aarchive'</SAMP> is functionally equivalent to
|
|
<SAMP>`-Bstatic'</SAMP>, and the other two keywords are functionally equivalent
|
|
to <SAMP>`-Bdynamic'</SAMP>. This option may be used any number of times.
|
|
|
|
<A NAME="IDX8"></A>
|
|
<A NAME="IDX9"></A>
|
|
<DT><CODE>-A<VAR>architecture</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX10"></A>
|
|
<DT><CODE>--architecture=<VAR>architecture</VAR></CODE>
|
|
<DD>
|
|
In the current release of <CODE>ld</CODE>, this option is useful only for the
|
|
Intel 960 family of architectures. In that <CODE>ld</CODE> configuration, the
|
|
<VAR>architecture</VAR> argument identifies the particular architecture in
|
|
the 960 family, enabling some safeguards and modifying the
|
|
archive-library search path. See section <A HREF="ld.html#SEC29"><CODE>ld</CODE> and the Intel 960 family</A>, for details.
|
|
|
|
Future releases of <CODE>ld</CODE> may support similar functionality for
|
|
other architecture families.
|
|
|
|
<A NAME="IDX11"></A>
|
|
<A NAME="IDX12"></A>
|
|
<A NAME="IDX13"></A>
|
|
<A NAME="IDX14"></A>
|
|
<A NAME="IDX15"></A>
|
|
<DT><CODE>-b <VAR>input-format</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--format=<VAR>input-format</VAR></CODE>
|
|
<DD>
|
|
<CODE>ld</CODE> may be configured to support more than one kind of object
|
|
file. If your <CODE>ld</CODE> is configured this way, you can use the
|
|
<SAMP>`-b'</SAMP> option to specify the binary format for input object files
|
|
that follow this option on the command line. Even when <CODE>ld</CODE> is
|
|
configured to support alternative object formats, you don't usually need
|
|
to specify this, as <CODE>ld</CODE> should be configured to expect as a
|
|
default input format the most usual format on each machine.
|
|
<VAR>input-format</VAR> is a text string, the name of a particular format
|
|
supported by the BFD libraries. (You can list the available binary
|
|
formats with <SAMP>`objdump -i'</SAMP>.)
|
|
See section <A HREF="ld.html#SEC30">BFD</A>.
|
|
|
|
You may want to use this option if you are linking files with an unusual
|
|
binary format. You can also use <SAMP>`-b'</SAMP> to switch formats explicitly (when
|
|
linking object files of different formats), by including
|
|
<SAMP>`-b <VAR>input-format</VAR>'</SAMP> before each group of object files in a
|
|
particular format.
|
|
|
|
The default format is taken from the environment variable
|
|
<CODE>GNUTARGET</CODE>.
|
|
See section <A HREF="ld.html#SEC4">Environment Variables</A>.
|
|
You can also define the input
|
|
format from a script, using the command <CODE>TARGET</CODE>; see section <A HREF="ld.html#SEC26">Option Commands</A>.
|
|
|
|
<A NAME="IDX16"></A>
|
|
<A NAME="IDX17"></A>
|
|
<A NAME="IDX18"></A>
|
|
<DT><CODE>-c <VAR>MRI-commandfile</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--mri-script=<VAR>MRI-commandfile</VAR></CODE>
|
|
<DD>
|
|
For compatibility with linkers produced by MRI, <CODE>ld</CODE> accepts script
|
|
files written in an alternate, restricted command language, described in
|
|
section <A HREF="ld.html#SEC37">MRI Compatible Script Files</A>. Introduce MRI script files with
|
|
the option <SAMP>`-c'</SAMP>; use the <SAMP>`-T'</SAMP> option to run linker
|
|
scripts written in the general-purpose <CODE>ld</CODE> scripting language.
|
|
If <VAR>MRI-cmdfile</VAR> does not exist, <CODE>ld</CODE> looks for it in the directories
|
|
specified by any <SAMP>`-L'</SAMP> options.
|
|
|
|
<A NAME="IDX19"></A>
|
|
<A NAME="IDX20"></A>
|
|
<A NAME="IDX21"></A>
|
|
<A NAME="IDX22"></A>
|
|
<DT><CODE>-d</CODE>
|
|
<DD>
|
|
<DT><CODE>-dc</CODE>
|
|
<DD>
|
|
<DT><CODE>-dp</CODE>
|
|
<DD>
|
|
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 <SAMP>`-r'</SAMP>). The script command
|
|
<CODE>FORCE_COMMON_ALLOCATION</CODE> has the same effect. See section <A HREF="ld.html#SEC26">Option Commands</A>.
|
|
|
|
<A NAME="IDX23"></A>
|
|
<A NAME="IDX24"></A>
|
|
<A NAME="IDX25"></A>
|
|
<DT><CODE>-e <VAR>entry</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--entry=<VAR>entry</VAR></CODE>
|
|
<DD>
|
|
Use <VAR>entry</VAR> as the explicit symbol for beginning execution of your
|
|
program, rather than the default entry point. See section <A HREF="ld.html#SEC24">The Entry Point</A>, for a
|
|
discussion of defaults and other ways of specifying the
|
|
entry point.
|
|
|
|
<A NAME="IDX26"></A>
|
|
<A NAME="IDX27"></A>
|
|
<A NAME="IDX28"></A>
|
|
<DT><CODE>-E</CODE>
|
|
<DD>
|
|
<DT><CODE>--export-dynamic</CODE>
|
|
<DD>
|
|
When creating a dynamically linked executable, add all symbols to the
|
|
dynamic symbol table. The dynamic symbol table is the set of symbols
|
|
which are visible from dynamic objects at run time.
|
|
|
|
If you do not use this option, the dynamic symbol table will normally
|
|
contain only those symbols which are referenced by some dynamic object
|
|
mentioned in the link.
|
|
|
|
If you use <CODE>dlopen</CODE> to load a dynamic object which needs to refer
|
|
back to the symbols defined by the program, rather than some other
|
|
dynamic object, then you will probably need to use this option when
|
|
linking the program itself.
|
|
|
|
<A NAME="IDX29"></A>
|
|
<A NAME="IDX30"></A>
|
|
<DT><CODE>-f</CODE>
|
|
<DD>
|
|
<DT><CODE>--auxiliary <VAR>name</VAR></CODE>
|
|
<DD>
|
|
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 <VAR>name</VAR>.
|
|
|
|
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
|
|
<VAR>name</VAR>. If there is one, it will be used instead of the definition
|
|
in the filter object. The shared object <VAR>name</VAR> need not exist.
|
|
Thus the shared object <VAR>name</VAR> 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.
|
|
|
|
<A NAME="IDX31"></A>
|
|
<A NAME="IDX32"></A>
|
|
<DT><CODE>-F <VAR>name</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--filter <VAR>name</VAR></CODE>
|
|
<DD>
|
|
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 <VAR>name</VAR>.
|
|
|
|
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 <VAR>name</VAR>. Thus the filter object can be
|
|
used to select a subset of the symbols provided by the object
|
|
<VAR>name</VAR>.
|
|
|
|
Some older linkers used the <CODE>-F</CODE> 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 <CODE>-b</CODE>, <CODE>--format</CODE>, <CODE>--oformat</CODE> options, the
|
|
<CODE>TARGET</CODE> command in linker scripts, and the <CODE>GNUTARGET</CODE>
|
|
environment variable. The GNU linker will ignore the <CODE>-F</CODE>
|
|
option when not creating an ELF shared object.
|
|
|
|
<A NAME="IDX33"></A>
|
|
<DT><CODE>--force-exe-suffix</CODE>
|
|
<DD>
|
|
Make sure that an output file has a .exe suffix.
|
|
|
|
If a successfully built fully linked output file does not have a
|
|
<CODE>.exe</CODE> or <CODE>.dll</CODE> suffix, this option forces the linker to copy
|
|
the output file to one of the same name with a <CODE>.exe</CODE> 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 <CODE>.exe</CODE> suffix.
|
|
|
|
<A NAME="IDX34"></A>
|
|
<DT><CODE>-g</CODE>
|
|
<DD>
|
|
Ignored. Provided for compatibility with other tools.
|
|
|
|
<A NAME="IDX35"></A>
|
|
<A NAME="IDX36"></A>
|
|
<A NAME="IDX37"></A>
|
|
<DT><CODE>-G<VAR>value</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--gpsize=<VAR>value</VAR></CODE>
|
|
<DD>
|
|
Set the maximum size of objects to be optimized using the GP register to
|
|
<VAR>size</VAR>. 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.
|
|
|
|
<A NAME="IDX38"></A>
|
|
<A NAME="IDX39"></A>
|
|
<A NAME="IDX40"></A>
|
|
<DT><CODE>-h<VAR>name</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>-soname=<VAR>name</VAR></CODE>
|
|
<DD>
|
|
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.
|
|
|
|
<A NAME="IDX41"></A>
|
|
<A NAME="IDX42"></A>
|
|
<DT><CODE>-i</CODE>
|
|
<DD>
|
|
Perform an incremental link (same as option <SAMP>`-r'</SAMP>).
|
|
|
|
<A NAME="IDX43"></A>
|
|
<A NAME="IDX44"></A>
|
|
<A NAME="IDX45"></A>
|
|
<DT><CODE>-l<VAR>archive</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--library=<VAR>archive</VAR></CODE>
|
|
<DD>
|
|
Add archive file <VAR>archive</VAR> to the list of files to link. This
|
|
option may be used any number of times. <CODE>ld</CODE> will search its
|
|
path-list for occurrences of <CODE>lib<VAR>archive</VAR>.a</CODE> for every
|
|
<VAR>archive</VAR> specified.
|
|
|
|
On systems which support shared libraries, <CODE>ld</CODE> may also search for
|
|
libraries with extensions other than <CODE>.a</CODE>. Specifically, on ELF
|
|
and SunOS systems, <CODE>ld</CODE> will search a directory for a library with
|
|
an extension of <CODE>.so</CODE> before searching for one with an extension of
|
|
<CODE>.a</CODE>. By convention, a <CODE>.so</CODE> 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 <CODE>-(</CODE> 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 <CODE>ld</CODE> on AIX, note that it is different from the
|
|
behaviour of the AIX linker.
|
|
|
|
<A NAME="IDX46"></A>
|
|
<A NAME="IDX47"></A>
|
|
<A NAME="IDX48"></A>
|
|
<DT><CODE>-L<VAR>searchdir</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--library-path=<VAR>searchdir</VAR></CODE>
|
|
<DD>
|
|
Add path <VAR>searchdir</VAR> to the list of paths that <CODE>ld</CODE> will search
|
|
for archive libraries and <CODE>ld</CODE> 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
|
|
<CODE>-L</CODE> options apply to all <CODE>-l</CODE> options, regardless of the
|
|
order in which the options appear.
|
|
|
|
The default set of paths searched (without being specified with
|
|
<SAMP>`-L'</SAMP>) depends on which emulation mode <CODE>ld</CODE> is using, and in
|
|
some cases also on how it was configured. See section <A HREF="ld.html#SEC4">Environment Variables</A>.
|
|
|
|
The paths can also be specified in a link script with the
|
|
<CODE>SEARCH_DIR</CODE> command. Directories specified this way are searched
|
|
at the point in which the linker script appears in the command line.
|
|
|
|
<A NAME="IDX49"></A>
|
|
<A NAME="IDX50"></A>
|
|
<DT><CODE>-m<VAR>emulation</VAR></CODE>
|
|
<DD>
|
|
Emulate the <VAR>emulation</VAR> linker. You can list the available
|
|
emulations with the <SAMP>`--verbose'</SAMP> or <SAMP>`-V'</SAMP> options.
|
|
|
|
If the <SAMP>`-m'</SAMP> option is not used, the emulation is taken from the
|
|
<CODE>LDEMULATION</CODE> environment variable, if that is defined.
|
|
|
|
Otherwise, the default emulation depends upon how the linker was
|
|
configured.
|
|
|
|
<A NAME="IDX51"></A>
|
|
<A NAME="IDX52"></A>
|
|
<A NAME="IDX53"></A>
|
|
<DT><CODE>-M</CODE>
|
|
<DD>
|
|
<DT><CODE>--print-map</CODE>
|
|
<DD>
|
|
Print a link map to the standard output. A link map provides
|
|
information about the link, including the following:
|
|
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
Where object files and symbols are mapped into memory.
|
|
<LI>
|
|
|
|
How common symbols are allocated.
|
|
<LI>
|
|
|
|
All archive members included in the link, with a mention of the symbol
|
|
which caused the archive member to be brought in.
|
|
</UL>
|
|
|
|
<A NAME="IDX54"></A>
|
|
<A NAME="IDX55"></A>
|
|
<A NAME="IDX56"></A>
|
|
<A NAME="IDX57"></A>
|
|
<DT><CODE>-n</CODE>
|
|
<DD>
|
|
<DT><CODE>--nmagic</CODE>
|
|
<DD>
|
|
Set the text segment to be read only, and mark the output as
|
|
<CODE>NMAGIC</CODE> if possible.
|
|
|
|
<A NAME="IDX58"></A>
|
|
<A NAME="IDX59"></A>
|
|
<A NAME="IDX60"></A>
|
|
<A NAME="IDX61"></A>
|
|
<DT><CODE>-N</CODE>
|
|
<DD>
|
|
<DT><CODE>--omagic</CODE>
|
|
<DD>
|
|
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 <CODE>OMAGIC</CODE>.
|
|
|
|
<A NAME="IDX62"></A>
|
|
<A NAME="IDX63"></A>
|
|
<A NAME="IDX64"></A>
|
|
<DT><CODE>-o <VAR>output</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--output=<VAR>output</VAR></CODE>
|
|
<DD>
|
|
Use <VAR>output</VAR> as the name for the program produced by <CODE>ld</CODE>; if this
|
|
option is not specified, the name <TT>`a.out'</TT> is used by default. The
|
|
script command <CODE>OUTPUT</CODE> can also specify the output file name.
|
|
|
|
<A NAME="IDX65"></A>
|
|
<A NAME="IDX66"></A>
|
|
<A NAME="IDX67"></A>
|
|
<A NAME="IDX68"></A>
|
|
<DT><CODE>-r</CODE>
|
|
<DD>
|
|
<DT><CODE>--relocateable</CODE>
|
|
<DD>
|
|
Generate relocatable output--i.e., generate an output file that can in
|
|
turn serve as input to <CODE>ld</CODE>. This is often called <EM>partial
|
|
linking</EM>. As a side effect, in environments that support standard Unix
|
|
magic numbers, this option also sets the output file's magic number to
|
|
<CODE>OMAGIC</CODE>.
|
|
If this option is not specified, an absolute file is produced. When
|
|
linking C++ programs, this option <EM>will not</EM> resolve references to
|
|
constructors; to do that, use <SAMP>`-Ur'</SAMP>.
|
|
|
|
This option does the same thing as <SAMP>`-i'</SAMP>.
|
|
|
|
<A NAME="IDX69"></A>
|
|
<A NAME="IDX70"></A>
|
|
<A NAME="IDX71"></A>
|
|
<DT><CODE>-R <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--just-symbols=<VAR>filename</VAR></CODE>
|
|
<DD>
|
|
Read symbol names and their addresses from <VAR>filename</VAR>, 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 <CODE>-R</CODE> option is
|
|
followed by a directory name, rather than a file name, it is treated as
|
|
the <CODE>-rpath</CODE> option.
|
|
|
|
<A NAME="IDX72"></A>
|
|
<A NAME="IDX73"></A>
|
|
<A NAME="IDX74"></A>
|
|
<DT><CODE>-s</CODE>
|
|
<DD>
|
|
<DT><CODE>--strip-all</CODE>
|
|
<DD>
|
|
Omit all symbol information from the output file.
|
|
|
|
<A NAME="IDX75"></A>
|
|
<A NAME="IDX76"></A>
|
|
<A NAME="IDX77"></A>
|
|
<DT><CODE>-S</CODE>
|
|
<DD>
|
|
<DT><CODE>--strip-debug</CODE>
|
|
<DD>
|
|
Omit debugger symbol information (but not all symbols) from the output file.
|
|
|
|
<A NAME="IDX78"></A>
|
|
<A NAME="IDX79"></A>
|
|
<A NAME="IDX80"></A>
|
|
<DT><CODE>-t</CODE>
|
|
<DD>
|
|
<DT><CODE>--trace</CODE>
|
|
<DD>
|
|
Print the names of the input files as <CODE>ld</CODE> processes them.
|
|
|
|
<A NAME="IDX81"></A>
|
|
<A NAME="IDX82"></A>
|
|
<A NAME="IDX83"></A>
|
|
<DT><CODE>-T <VAR>commandfile</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--script=<VAR>commandfile</VAR></CODE>
|
|
<DD>
|
|
Read link commands from the file <VAR>commandfile</VAR>. These commands
|
|
replace <CODE>ld</CODE>'s default link script (rather than adding to it), so
|
|
<VAR>commandfile</VAR> 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
|
|
<CODE>SECTIONS</CODE> or <CODE>MEMORY</CODE> command. See section <A HREF="ld.html#SEC5">Command Language</A>. If
|
|
<VAR>commandfile</VAR> does not exist, <CODE>ld</CODE> looks for it in the
|
|
directories specified by any preceding <SAMP>`-L'</SAMP> options. Multiple
|
|
<SAMP>`-T'</SAMP> options accumulate.
|
|
|
|
<A NAME="IDX84"></A>
|
|
<A NAME="IDX85"></A>
|
|
<A NAME="IDX86"></A>
|
|
<DT><CODE>-u <VAR>symbol</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--undefined=<VAR>symbol</VAR></CODE>
|
|
<DD>
|
|
Force <VAR>symbol</VAR> to be entered in the output file as an undefined symbol.
|
|
Doing this may, for example, trigger linking of additional modules from
|
|
standard libraries. <SAMP>`-u'</SAMP> may be repeated with different option
|
|
arguments to enter additional undefined symbols.
|
|
|
|
<A NAME="IDX87"></A>
|
|
<A NAME="IDX88"></A>
|
|
<A NAME="IDX89"></A>
|
|
<A NAME="IDX90"></A>
|
|
<DT><CODE>-v</CODE>
|
|
<DD>
|
|
<DT><CODE>--version</CODE>
|
|
<DD>
|
|
<DT><CODE>-V</CODE>
|
|
<DD>
|
|
Display the version number for <CODE>ld</CODE>. The <CODE>-V</CODE> option also
|
|
lists the supported emulations.
|
|
|
|
<A NAME="IDX91"></A>
|
|
<A NAME="IDX92"></A>
|
|
<A NAME="IDX93"></A>
|
|
<DT><CODE>-x</CODE>
|
|
<DD>
|
|
<DT><CODE>--discard-all</CODE>
|
|
<DD>
|
|
Delete all local symbols.
|
|
|
|
<A NAME="IDX94"></A>
|
|
<A NAME="IDX95"></A>
|
|
<A NAME="IDX96"></A>
|
|
<A NAME="IDX97"></A>
|
|
<DT><CODE>-X</CODE>
|
|
<DD>
|
|
<DT><CODE>--discard-locals</CODE>
|
|
<DD>
|
|
Delete all temporary local symbols. For most targets, this is all local
|
|
symbols whose names begin with <SAMP>`L'</SAMP>.
|
|
|
|
<A NAME="IDX98"></A>
|
|
<A NAME="IDX99"></A>
|
|
<A NAME="IDX100"></A>
|
|
<DT><CODE>-y <VAR>symbol</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>--trace-symbol=<VAR>symbol</VAR></CODE>
|
|
<DD>
|
|
Print the name of each linked file in which <VAR>symbol</VAR> 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.
|
|
|
|
<A NAME="IDX101"></A>
|
|
<DT><CODE>-Y <VAR>path</VAR></CODE>
|
|
<DD>
|
|
Add <VAR>path</VAR> to the default library search path. This option exists
|
|
for Solaris compatibility.
|
|
|
|
<A NAME="IDX102"></A>
|
|
<DT><CODE>-z <VAR>keyword</VAR></CODE>
|
|
<DD>
|
|
This option is ignored for Solaris compatibility.
|
|
|
|
<A NAME="IDX103"></A>
|
|
<A NAME="IDX104"></A>
|
|
<DT><CODE>-( <VAR>archives</VAR> -)</CODE>
|
|
<DD>
|
|
<DT><CODE>--start-group <VAR>archives</VAR> --end-group</CODE>
|
|
<DD>
|
|
The <VAR>archives</VAR> should be a list of archive files. They may be
|
|
either explicit file names, or <SAMP>`-l'</SAMP> 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.
|
|
|
|
<A NAME="IDX105"></A>
|
|
<DT><CODE>-assert <VAR>keyword</VAR></CODE>
|
|
<DD>
|
|
This option is ignored for SunOS compatibility.
|
|
|
|
<A NAME="IDX106"></A>
|
|
<A NAME="IDX107"></A>
|
|
<A NAME="IDX108"></A>
|
|
<DT><CODE>-Bdynamic</CODE>
|
|
<DD>
|
|
<DT><CODE>-dy</CODE>
|
|
<DD>
|
|
<DT><CODE>-call_shared</CODE>
|
|
<DD>
|
|
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
|
|
<CODE>-l</CODE> options which follow it.
|
|
|
|
<A NAME="IDX109"></A>
|
|
<A NAME="IDX110"></A>
|
|
<A NAME="IDX111"></A>
|
|
<A NAME="IDX112"></A>
|
|
<DT><CODE>-Bstatic</CODE>
|
|
<DD>
|
|
<DT><CODE>-dn</CODE>
|
|
<DD>
|
|
<DT><CODE>-non_shared</CODE>
|
|
<DD>
|
|
<DT><CODE>-static</CODE>
|
|
<DD>
|
|
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 <CODE>-l</CODE> options which follow it.
|
|
|
|
<A NAME="IDX113"></A>
|
|
<DT><CODE>-Bsymbolic</CODE>
|
|
<DD>
|
|
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.
|
|
|
|
<A NAME="IDX114"></A>
|
|
<A NAME="IDX115"></A>
|
|
<DT><CODE>--cref</CODE>
|
|
<DD>
|
|
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.
|
|
|
|
<A NAME="IDX116"></A>
|
|
<A NAME="IDX117"></A>
|
|
<DT><CODE>--defsym <VAR>symbol</VAR>=<VAR>expression</VAR></CODE>
|
|
<DD>
|
|
Create a global symbol in the output file, containing the absolute
|
|
address given by <VAR>expression</VAR>. 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 <VAR>expression</VAR> in this
|
|
context: you may give a hexadecimal constant or the name of an existing
|
|
symbol, or use <CODE>+</CODE> and <CODE>-</CODE> to add or subtract hexadecimal
|
|
constants or symbols. If you need more elaborate expressions, consider
|
|
using the linker command language from a script (see section <A HREF="ld.html#SEC13">Assignment: Defining Symbols</A>). <EM>Note:</EM> there should be no
|
|
white space between <VAR>symbol</VAR>, the equals sign ("<KBD>=</KBD>"), and
|
|
<VAR>expression</VAR>.
|
|
|
|
<A NAME="IDX118"></A>
|
|
<A NAME="IDX119"></A>
|
|
<DT><CODE>--dynamic-linker <VAR>file</VAR></CODE>
|
|
<DD>
|
|
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.
|
|
|
|
<A NAME="IDX120"></A>
|
|
<A NAME="IDX121"></A>
|
|
<A NAME="IDX122"></A>
|
|
<DT><CODE>-EB</CODE>
|
|
<DD>
|
|
Link big-endian objects. This affects the default output format.
|
|
|
|
<A NAME="IDX123"></A>
|
|
<A NAME="IDX124"></A>
|
|
<DT><CODE>-EL</CODE>
|
|
<DD>
|
|
Link little-endian objects. This affects the default output format.
|
|
|
|
<A NAME="IDX125"></A>
|
|
<A NAME="IDX126"></A>
|
|
<DT><CODE>--embedded-relocs</CODE>
|
|
<DD>
|
|
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.
|
|
|
|
<A NAME="IDX127"></A>
|
|
<A NAME="IDX128"></A>
|
|
<A NAME="IDX129"></A>
|
|
<DT><CODE>--help</CODE>
|
|
<DD>
|
|
Print a summary of the command-line options on the standard output and exit.
|
|
|
|
<A NAME="IDX130"></A>
|
|
<DT><CODE>-Map <VAR>mapfile</VAR></CODE>
|
|
<DD>
|
|
Print a link map to the file <VAR>mapfile</VAR>. See the description of the
|
|
<SAMP>`-M'</SAMP> option, above.
|
|
|
|
<A NAME="IDX131"></A>
|
|
<A NAME="IDX132"></A>
|
|
<DT><CODE>--no-keep-memory</CODE>
|
|
<DD>
|
|
<CODE>ld</CODE> normally optimizes for speed over memory usage by caching the
|
|
symbol tables of input files in memory. This option tells <CODE>ld</CODE> to
|
|
instead optimize for memory usage, by rereading the symbol tables as
|
|
necessary. This may be required if <CODE>ld</CODE> runs out of memory space
|
|
while linking a large executable.
|
|
|
|
<A NAME="IDX133"></A>
|
|
<DT><CODE>--no-warn-mismatch</CODE>
|
|
<DD>
|
|
Normally <CODE>ld</CODE> will give an error if you try to link together input
|
|
files that are mismatched for some reason, perhaps because they have
|
|
been compiled for different processors or for different endiannesses.
|
|
This option tells <CODE>ld</CODE> that it should silently permit such possible
|
|
errors. This option should only be used with care, in cases when you
|
|
have taken some special action that ensures that the linker errors are
|
|
inappropriate.
|
|
|
|
<A NAME="IDX134"></A>
|
|
<DT><CODE>--no-whole-archive</CODE>
|
|
<DD>
|
|
Turn off the effect of the <CODE>--whole-archive</CODE> option for subsequent
|
|
archive files.
|
|
|
|
<A NAME="IDX135"></A>
|
|
<A NAME="IDX136"></A>
|
|
<DT><CODE>--noinhibit-exec</CODE>
|
|
<DD>
|
|
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.
|
|
|
|
<A NAME="IDX137"></A>
|
|
<DT><CODE>--oformat <VAR>output-format</VAR></CODE>
|
|
<DD>
|
|
<CODE>ld</CODE> may be configured to support more than one kind of object
|
|
file. If your <CODE>ld</CODE> is configured this way, you can use the
|
|
<SAMP>`--oformat'</SAMP> option to specify the binary format for the output
|
|
object file. Even when <CODE>ld</CODE> is configured to support alternative
|
|
object formats, you don't usually need to specify this, as <CODE>ld</CODE>
|
|
should be configured to produce as a default output format the most
|
|
usual format on each machine. <VAR>output-format</VAR> is a text string, the
|
|
name of a particular format supported by the BFD libraries. (You can
|
|
list the available binary formats with <SAMP>`objdump -i'</SAMP>.) The script
|
|
command <CODE>OUTPUT_FORMAT</CODE> can also specify the output format, but
|
|
this option overrides it. See section <A HREF="ld.html#SEC30">BFD</A>.
|
|
|
|
<A NAME="IDX138"></A>
|
|
<DT><CODE>-qmagic</CODE>
|
|
<DD>
|
|
This option is ignored for Linux compatibility.
|
|
|
|
<A NAME="IDX139"></A>
|
|
<DT><CODE>-Qy</CODE>
|
|
<DD>
|
|
This option is ignored for SVR4 compatibility.
|
|
|
|
<A NAME="IDX140"></A>
|
|
<A NAME="IDX141"></A>
|
|
<A NAME="IDX142"></A>
|
|
<DT><CODE>--relax</CODE>
|
|
<DD>
|
|
An option with machine dependent effects.
|
|
This option is only supported on a few targets.
|
|
See section <A HREF="ld.html#SEC28"><CODE>ld</CODE> and the H8/300</A>.
|
|
See section <A HREF="ld.html#SEC29"><CODE>ld</CODE> and the Intel 960 family</A>.
|
|
|
|
On some platforms, the <SAMP>`--relax'</SAMP> 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, <SAMP>`--relax'</SAMP> is accepted,
|
|
but ignored.
|
|
|
|
<A NAME="IDX143"></A>
|
|
<A NAME="IDX144"></A>
|
|
<A NAME="IDX145"></A>
|
|
<DT><CODE>--retain-symbols-file <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
Retain <EM>only</EM> the symbols listed in the file <VAR>filename</VAR>,
|
|
discarding all others. <VAR>filename</VAR> 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.
|
|
|
|
<SAMP>`--retain-symbols-file'</SAMP> does <EM>not</EM> discard undefined symbols,
|
|
or symbols needed for relocations.
|
|
|
|
You may only specify <SAMP>`--retain-symbols-file'</SAMP> once in the command
|
|
line. It overrides <SAMP>`-s'</SAMP> and <SAMP>`-S'</SAMP>.
|
|
|
|
<DT><CODE>-rpath <VAR>dir</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX146"></A>
|
|
<A NAME="IDX147"></A>
|
|
Add a directory to the runtime library search path. This is used when
|
|
linking an ELF executable with shared objects. All <CODE>-rpath</CODE>
|
|
arguments are concatenated and passed to the runtime linker, which uses
|
|
them to locate shared objects at runtime. The <CODE>-rpath</CODE> option is
|
|
also used when locating shared objects which are needed by shared
|
|
objects explicitly included in the link; see the description of the
|
|
<CODE>-rpath-link</CODE> option. If <CODE>-rpath</CODE> is not used when linking an
|
|
ELF executable, the contents of the environment variable
|
|
<CODE>LD_RUN_PATH</CODE> will be used if it is defined.
|
|
|
|
The <CODE>-rpath</CODE> option may also be used on SunOS. By default, on
|
|
SunOS, the linker will form a runtime search patch out of all the
|
|
<CODE>-L</CODE> options it is given. If a <CODE>-rpath</CODE> option is used, the
|
|
runtime search path will be formed exclusively using the <CODE>-rpath</CODE>
|
|
options, ignoring the <CODE>-L</CODE> options. This can be useful when using
|
|
gcc, which adds many <CODE>-L</CODE> options which may be on NFS mounted
|
|
filesystems.
|
|
|
|
For compatibility with other ELF linkers, if the <CODE>-R</CODE> option is
|
|
followed by a directory name, rather than a file name, it is treated as
|
|
the <CODE>-rpath</CODE> option.
|
|
|
|
<A NAME="IDX148"></A>
|
|
<A NAME="IDX149"></A>
|
|
<DT><CODE>-rpath-link <VAR>DIR</VAR></CODE>
|
|
<DD>
|
|
When using ELF or SunOS, one shared library may require another. This
|
|
happens when an <CODE>ld -shared</CODE> 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 <CODE>-rpath-link</CODE> option
|
|
specifies the first set of directories to search. The
|
|
<CODE>-rpath-link</CODE> 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.
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
Any directories specified by <CODE>-rpath-link</CODE> options.
|
|
<LI>
|
|
|
|
Any directories specified by <CODE>-rpath</CODE> options. The difference
|
|
between <CODE>-rpath</CODE> and <CODE>-rpath-link</CODE> is that directories
|
|
specified by <CODE>-rpath</CODE> options are included in the executable and
|
|
used at runtime, whereas the <CODE>-rpath-link</CODE> option is only effective
|
|
at link time.
|
|
<LI>
|
|
|
|
On an ELF system, if the <CODE>-rpath</CODE> and <CODE>rpath-link</CODE> options
|
|
were not used, search the contents of the environment variable
|
|
<CODE>LD_RUN_PATH</CODE>.
|
|
<LI>
|
|
|
|
On SunOS, if the <CODE>-rpath</CODE> option was not used, search any
|
|
directories specified using <CODE>-L</CODE> options.
|
|
<LI>
|
|
|
|
For a native linker, the contents of the environment variable
|
|
<CODE>LD_LIBRARY_PATH</CODE>.
|
|
<LI>
|
|
|
|
The default directories, normally <TT>`/lib'</TT> and <TT>`/usr/lib'</TT>.
|
|
</OL>
|
|
|
|
If the required shared library is not found, the linker will issue a
|
|
warning and continue with the link.
|
|
|
|
<A NAME="IDX150"></A>
|
|
<A NAME="IDX151"></A>
|
|
<DT><CODE>-shared</CODE>
|
|
<DD>
|
|
<DT><CODE>-Bshareable</CODE>
|
|
<DD>
|
|
<A NAME="IDX152"></A>
|
|
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 <CODE>-e</CODE> option is not used and there are
|
|
undefined symbols in the link.
|
|
|
|
<DT><CODE>--sort-common</CODE>
|
|
<DD>
|
|
<A NAME="IDX153"></A>
|
|
This option tells <CODE>ld</CODE> 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.
|
|
|
|
<A NAME="IDX154"></A>
|
|
<DT><CODE>--split-by-file</CODE>
|
|
<DD>
|
|
Similar to <CODE>--split-by-reloc</CODE> but creates a new output section for
|
|
each input file.
|
|
|
|
<A NAME="IDX155"></A>
|
|
<DT><CODE>--split-by-reloc <VAR>count</VAR></CODE>
|
|
<DD>
|
|
Trys to creates extra sections in the output file so that no single
|
|
output section in the file contains more than <VAR>count</VAR> 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 <VAR>count</VAR> relocations one output section will contain that
|
|
many relocations.
|
|
|
|
<A NAME="IDX156"></A>
|
|
<DT><CODE>--stats</CODE>
|
|
<DD>
|
|
Compute and display statistics about the operation of the linker, such
|
|
as execution time and memory usage.
|
|
|
|
<A NAME="IDX157"></A>
|
|
<A NAME="IDX158"></A>
|
|
<DT><CODE>--traditional-format</CODE>
|
|
<DD>
|
|
For some targets, the output of <CODE>ld</CODE> is different in some ways from
|
|
the output of some existing linker. This switch requests <CODE>ld</CODE> to
|
|
use the traditional format instead.
|
|
|
|
<A NAME="IDX159"></A>
|
|
For example, on SunOS, <CODE>ld</CODE> 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
|
|
<CODE>dbx</CODE> program can not read the resulting program (<CODE>gdb</CODE> has no
|
|
trouble). The <SAMP>`--traditional-format'</SAMP> switch tells <CODE>ld</CODE> to not
|
|
combine duplicate entries.
|
|
|
|
<A NAME="IDX160"></A>
|
|
<A NAME="IDX161"></A>
|
|
<A NAME="IDX162"></A>
|
|
<A NAME="IDX163"></A>
|
|
<DT><CODE>-Tbss <VAR>org</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>-Tdata <VAR>org</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>-Ttext <VAR>org</VAR></CODE>
|
|
<DD>
|
|
Use <VAR>org</VAR> as the starting address for--respectively--the
|
|
<CODE>bss</CODE>, <CODE>data</CODE>, or the <CODE>text</CODE> segment of the output file.
|
|
<VAR>org</VAR> must be a single hexadecimal integer;
|
|
for compatibility with other linkers, you may omit the leading
|
|
<SAMP>`0x'</SAMP> usually associated with hexadecimal values.
|
|
|
|
<A NAME="IDX164"></A>
|
|
<A NAME="IDX165"></A>
|
|
<DT><CODE>-Ur</CODE>
|
|
<DD>
|
|
For anything other than C++ programs, this option is equivalent to
|
|
<SAMP>`-r'</SAMP>: it generates relocatable output--i.e., an output file that can in
|
|
turn serve as input to <CODE>ld</CODE>. When linking C++ programs, <SAMP>`-Ur'</SAMP>
|
|
<EM>does</EM> resolve references to constructors, unlike <SAMP>`-r'</SAMP>.
|
|
It does not work to use <SAMP>`-Ur'</SAMP> on files that were themselves linked
|
|
with <SAMP>`-Ur'</SAMP>; once the constructor table has been built, it cannot
|
|
be added to. Use <SAMP>`-Ur'</SAMP> only for the last partial link, and
|
|
<SAMP>`-r'</SAMP> for the others.
|
|
|
|
<A NAME="IDX166"></A>
|
|
<A NAME="IDX167"></A>
|
|
<DT><CODE>--verbose</CODE>
|
|
<DD>
|
|
Display the version number for <CODE>ld</CODE> 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.
|
|
|
|
<A NAME="IDX168"></A>
|
|
<A NAME="IDX169"></A>
|
|
<DT><CODE>--version-script=<VAR>version-scriptfile</VAR></CODE>
|
|
<DD>
|
|
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.
|
|
See section <A HREF="ld.html#SEC25">Version Script</A>.
|
|
|
|
<A NAME="IDX170"></A>
|
|
<A NAME="IDX171"></A>
|
|
<A NAME="IDX172"></A>
|
|
<DT><CODE>--warn-common</CODE>
|
|
<DD>
|
|
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:
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`int i = 1;'</SAMP>
|
|
<DD>
|
|
A definition, which goes in the initialized data section of the output
|
|
file.
|
|
|
|
<DT><SAMP>`extern int i;'</SAMP>
|
|
<DD>
|
|
An undefined reference, which does not allocate space.
|
|
There must be either a definition or a common symbol for the
|
|
variable somewhere.
|
|
|
|
<DT><SAMP>`int i;'</SAMP>
|
|
<DD>
|
|
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.
|
|
</DL>
|
|
|
|
The <SAMP>`--warn-common'</SAMP> 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.
|
|
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
Turning a common symbol into a reference, because there is already a
|
|
definition for the symbol.
|
|
|
|
<PRE>
|
|
<VAR>file</VAR>(<VAR>section</VAR>): warning: common of `<VAR>symbol</VAR>'
|
|
overridden by definition
|
|
<VAR>file</VAR>(<VAR>section</VAR>): warning: defined here
|
|
</PRE>
|
|
|
|
<LI>
|
|
|
|
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.
|
|
|
|
<PRE>
|
|
<VAR>file</VAR>(<VAR>section</VAR>): warning: definition of `<VAR>symbol</VAR>'
|
|
overriding common
|
|
<VAR>file</VAR>(<VAR>section</VAR>): warning: common is here
|
|
</PRE>
|
|
|
|
<LI>
|
|
|
|
Merging a common symbol with a previous same-sized common symbol.
|
|
|
|
<PRE>
|
|
<VAR>file</VAR>(<VAR>section</VAR>): warning: multiple common
|
|
of `<VAR>symbol</VAR>'
|
|
<VAR>file</VAR>(<VAR>section</VAR>): warning: previous common is here
|
|
</PRE>
|
|
|
|
<LI>
|
|
|
|
Merging a common symbol with a previous larger common symbol.
|
|
|
|
<PRE>
|
|
<VAR>file</VAR>(<VAR>section</VAR>): warning: common of `<VAR>symbol</VAR>'
|
|
overridden by larger common
|
|
<VAR>file</VAR>(<VAR>section</VAR>): warning: larger common is here
|
|
</PRE>
|
|
|
|
<LI>
|
|
|
|
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.
|
|
|
|
<PRE>
|
|
<VAR>file</VAR>(<VAR>section</VAR>): warning: common of `<VAR>symbol</VAR>'
|
|
overriding smaller common
|
|
<VAR>file</VAR>(<VAR>section</VAR>): warning: smaller common is here
|
|
</PRE>
|
|
|
|
</OL>
|
|
|
|
<A NAME="IDX173"></A>
|
|
<DT><CODE>--warn-constructors</CODE>
|
|
<DD>
|
|
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.
|
|
|
|
<A NAME="IDX174"></A>
|
|
<DT><CODE>--warn-multiple-gp</CODE>
|
|
<DD>
|
|
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.
|
|
|
|
<A NAME="IDX175"></A>
|
|
<A NAME="IDX176"></A>
|
|
<A NAME="IDX177"></A>
|
|
<DT><CODE>--warn-once</CODE>
|
|
<DD>
|
|
Only warn once for each undefined symbol, rather than once per module
|
|
which refers to it.
|
|
|
|
<A NAME="IDX178"></A>
|
|
<A NAME="IDX179"></A>
|
|
<A NAME="IDX180"></A>
|
|
<DT><CODE>--warn-section-align</CODE>
|
|
<DD>
|
|
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 <CODE>SECTIONS</CODE> command does not specify a start address for
|
|
the section (see section <A HREF="ld.html#SEC17">Specifying Output Sections</A>).
|
|
|
|
<A NAME="IDX181"></A>
|
|
<A NAME="IDX182"></A>
|
|
<DT><CODE>--whole-archive</CODE>
|
|
<DD>
|
|
For each archive mentioned on the command line after the
|
|
<CODE>--whole-archive</CODE> 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.
|
|
|
|
<A NAME="IDX183"></A>
|
|
<DT><CODE>--wrap <VAR>symbol</VAR></CODE>
|
|
<DD>
|
|
Use a wrapper function for <VAR>symbol</VAR>. Any undefined reference to
|
|
<VAR>symbol</VAR> will be resolved to <CODE>__wrap_<VAR>symbol</VAR></CODE>. Any
|
|
undefined reference to <CODE>__real_<VAR>symbol</VAR></CODE> will be resolved to
|
|
<VAR>symbol</VAR>.
|
|
|
|
This can be used to provide a wrapper for a system function. The
|
|
wrapper function should be called <CODE>__wrap_<VAR>symbol</VAR></CODE>. If it
|
|
wishes to call the system function, it should call
|
|
<CODE>__real_<VAR>symbol</VAR></CODE>.
|
|
|
|
Here is a trivial example:
|
|
|
|
|
|
<PRE>
|
|
void *
|
|
__wrap_malloc (int c)
|
|
{
|
|
printf ("malloc called with %ld\n", c);
|
|
return __real_malloc (c);
|
|
}
|
|
</PRE>
|
|
|
|
If you link other code with this file using <CODE>--wrap malloc</CODE>, then
|
|
all calls to <CODE>malloc</CODE> will call the function <CODE>__wrap_malloc</CODE>
|
|
instead. The call to <CODE>__real_malloc</CODE> in <CODE>__wrap_malloc</CODE> will
|
|
call the real <CODE>malloc</CODE> function.
|
|
|
|
You may wish to provide a <CODE>__real_malloc</CODE> function as well, so that
|
|
links without the <CODE>--wrap</CODE> option will succeed. If you do this,
|
|
you should not put the definition of <CODE>__real_malloc</CODE> in the same
|
|
file as <CODE>__wrap_malloc</CODE>; if you do, the assembler may resolve the
|
|
call before the linker has a chance to wrap it to <CODE>malloc</CODE>.
|
|
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC4" HREF="ld.html#TOC4">Environment Variables</A></H2>
|
|
|
|
<P>
|
|
You can change the behavior of <CODE>ld</CODE> with the environment variables
|
|
<CODE>GNUTARGET</CODE> and <CODE>LDEMULATION</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX184"></A>
|
|
<A NAME="IDX185"></A>
|
|
<CODE>GNUTARGET</CODE> determines the input-file object format if you don't
|
|
use <SAMP>`-b'</SAMP> (or its synonym <SAMP>`--format'</SAMP>). Its value should be one
|
|
of the BFD names for an input format (see section <A HREF="ld.html#SEC30">BFD</A>). If there is no
|
|
<CODE>GNUTARGET</CODE> in the environment, <CODE>ld</CODE> uses the natural format
|
|
of the target. If <CODE>GNUTARGET</CODE> is set to <CODE>default</CODE> 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.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX186"></A>
|
|
<A NAME="IDX187"></A>
|
|
<A NAME="IDX188"></A>
|
|
<CODE>LDEMULATION</CODE> determines the default emulation if you don't use the
|
|
<SAMP>`-m'</SAMP> option. The emulation can affect various aspects of linker
|
|
behaviour, particularly the default linker script. You can list the
|
|
available emulations with the <SAMP>`--verbose'</SAMP> or <SAMP>`-V'</SAMP> options. If
|
|
the <SAMP>`-m'</SAMP> option is not used, and the <CODE>LDEMULATION</CODE> environment
|
|
variable is not defined, the default emulation depends upon how the
|
|
linker was configured.
|
|
|
|
</P>
|
|
|
|
|
|
<H1><A NAME="SEC5" HREF="ld.html#TOC5">Command Language</A></H1>
|
|
|
|
<P>
|
|
<A NAME="IDX189"></A>
|
|
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:
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
input files
|
|
<LI>
|
|
|
|
file formats
|
|
<LI>
|
|
|
|
output file layout
|
|
<LI>
|
|
|
|
addresses of sections
|
|
<LI>
|
|
|
|
placement of common blocks
|
|
</UL>
|
|
|
|
<P>
|
|
You may supply a command file (also known as a linker script) to the
|
|
linker either explicitly through the <SAMP>`-T'</SAMP> option, or implicitly as
|
|
an ordinary file. Normally you should use the <SAMP>`-T'</SAMP> 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 <CODE>INPUT</CODE> or <CODE>GROUP</CODE>
|
|
commands.
|
|
|
|
</P>
|
|
<P>
|
|
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.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC6" HREF="ld.html#TOC6">Linker Scripts</A></H2>
|
|
<P>
|
|
The <CODE>ld</CODE> 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.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX190"></A>
|
|
<A NAME="IDX191"></A>
|
|
<A NAME="IDX192"></A>
|
|
<A NAME="IDX193"></A>
|
|
The most fundamental command of the <CODE>ld</CODE> command language is the
|
|
<CODE>SECTIONS</CODE> command (see section <A HREF="ld.html#SEC17">Specifying Output Sections</A>). Every meaningful command
|
|
script must have a <CODE>SECTIONS</CODE> command: it specifies a
|
|
"picture" of the output file's layout, in varying degrees of detail.
|
|
No other command is required in all cases.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>MEMORY</CODE> command complements <CODE>SECTIONS</CODE> by describing the
|
|
available memory in the target architecture. This command is optional;
|
|
if you don't use a <CODE>MEMORY</CODE> command, <CODE>ld</CODE> assumes sufficient
|
|
memory is available in a contiguous block for all output.
|
|
See section <A HREF="ld.html#SEC16">Memory Layout</A>.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX194"></A>
|
|
You may include comments in linker scripts just as in C: delimited
|
|
by <SAMP>`/*'</SAMP> and <SAMP>`*/'</SAMP>. As in C, comments are syntactically
|
|
equivalent to whitespace.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC7" HREF="ld.html#TOC7">Expressions</A></H2>
|
|
<P>
|
|
<A NAME="IDX195"></A>
|
|
<A NAME="IDX196"></A>
|
|
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:
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
All expressions evaluated as integers and
|
|
are of "long" or "unsigned long" type.
|
|
<LI>
|
|
|
|
All constants are integers.
|
|
<LI>
|
|
|
|
All of the C arithmetic operators are provided.
|
|
<LI>
|
|
|
|
You may reference, define, and create global variables.
|
|
<LI>
|
|
|
|
You may call special purpose built-in functions.
|
|
</UL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC8" HREF="ld.html#TOC8">Integers</A></H3>
|
|
<P>
|
|
<A NAME="IDX197"></A>
|
|
<A NAME="IDX198"></A>
|
|
An octal integer is <SAMP>`0'</SAMP> followed by zero or more of the octal
|
|
digits (<SAMP>`01234567'</SAMP>).
|
|
|
|
<PRE>
|
|
_as_octal = 0157255;
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX199"></A>
|
|
A decimal integer starts with a non-zero digit followed by zero or
|
|
more digits (<SAMP>`0123456789'</SAMP>).
|
|
|
|
<PRE>
|
|
_as_decimal = 57005;
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX200"></A>
|
|
<A NAME="IDX201"></A>
|
|
A hexadecimal integer is <SAMP>`0x'</SAMP> or <SAMP>`0X'</SAMP> followed by one or
|
|
more hexadecimal digits chosen from <SAMP>`0123456789abcdefABCDEF'</SAMP>.
|
|
|
|
<PRE>
|
|
_as_hex = 0xdead;
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX202"></A>
|
|
To write a negative integer, use
|
|
the prefix operator <SAMP>`-'</SAMP> (see section <A HREF="ld.html#SEC11">Operators</A>).
|
|
|
|
<PRE>
|
|
_as_neg = -57005;
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX203"></A>
|
|
<A NAME="IDX204"></A>
|
|
<A NAME="IDX205"></A>
|
|
<A NAME="IDX206"></A>
|
|
<A NAME="IDX207"></A>
|
|
Additionally the suffixes <CODE>K</CODE> and <CODE>M</CODE> may be used to scale a
|
|
constant by
|
|
respectively. For example, the following all refer to the same quantity:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
_fourk_1 = 4K;
|
|
_fourk_2 = 4096;
|
|
_fourk_3 = 0x1000;
|
|
</PRE>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC9" HREF="ld.html#TOC9">Symbol Names</A></H3>
|
|
<P>
|
|
<A NAME="IDX208"></A>
|
|
<A NAME="IDX209"></A>
|
|
<A NAME="IDX210"></A>
|
|
<A NAME="IDX211"></A>
|
|
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:
|
|
|
|
<PRE>
|
|
"SECTION" = 9;
|
|
"with a space" = "also with a space" + 10;
|
|
</PRE>
|
|
|
|
<P>
|
|
Since symbols can contain many non-alphabetic characters, it is safest
|
|
to delimit symbols with spaces. For example, <SAMP>`A-B'</SAMP> is one symbol,
|
|
whereas <SAMP>`A - B'</SAMP> is an expression involving subtraction.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC10" HREF="ld.html#TOC10">The Location Counter</A></H3>
|
|
<P>
|
|
<A NAME="IDX212"></A>
|
|
<A NAME="IDX213"></A>
|
|
<A NAME="IDX214"></A>
|
|
<A NAME="IDX215"></A>
|
|
The special linker variable <EM>dot</EM> <SAMP>`.'</SAMP> always contains the
|
|
current output location counter. Since the <CODE>.</CODE> always refers to
|
|
a location in an output section, it must always appear in an
|
|
expression within a <CODE>SECTIONS</CODE> command. The <CODE>.</CODE> 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 <CODE>.</CODE> symbol will cause the location counter to be moved.
|
|
<A NAME="IDX216"></A>
|
|
This may be used to create holes in the output section. The location
|
|
counter may never be moved backwards.
|
|
|
|
<PRE>
|
|
SECTIONS
|
|
{
|
|
output :
|
|
{
|
|
file1(.text)
|
|
. = . + 1000;
|
|
file2(.text)
|
|
. += 1000;
|
|
file3(.text)
|
|
} = 0x1234;
|
|
}
|
|
</PRE>
|
|
|
|
<P>
|
|
In the previous example, <CODE>file1</CODE> is located at the beginning of the
|
|
output section, then there is a 1000 byte gap. Then <CODE>file2</CODE>
|
|
appears, also with a 1000 byte gap following before <CODE>file3</CODE> is
|
|
loaded. The notation <SAMP>`= 0x1234'</SAMP> specifies what data to write in
|
|
the gaps (see section <A HREF="ld.html#SEC21">Optional Section Attributes</A>).
|
|
|
|
</P>
|
|
<P>
|
|
@vfill
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC11" HREF="ld.html#TOC11">Operators</A></H3>
|
|
<P>
|
|
<A NAME="IDX217"></A>
|
|
<A NAME="IDX218"></A>
|
|
<A NAME="IDX219"></A>
|
|
The linker recognizes the standard C set of arithmetic operators, with
|
|
the standard bindings and precedence levels:
|
|
{
|
|
@obeylines@parskip=0pt@parindent=0pt
|
|
@dag@quad Prefix operators.
|
|
@ddag@quad See section <A HREF="ld.html#SEC13">Assignment: Defining Symbols</A>.
|
|
}
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC12" HREF="ld.html#TOC12">Evaluation</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX220"></A>
|
|
<A NAME="IDX221"></A>
|
|
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.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC13" HREF="ld.html#TOC13">Assignment: Defining Symbols</A></H3>
|
|
<P>
|
|
<A NAME="IDX222"></A>
|
|
<A NAME="IDX223"></A>
|
|
<A NAME="IDX224"></A>
|
|
You may create global symbols, and assign values (addresses) to global
|
|
symbols, using any of the C assignment operators:
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE><VAR>symbol</VAR> = <VAR>expression</VAR> ;</CODE>
|
|
<DD>
|
|
<DT><CODE><VAR>symbol</VAR> &= <VAR>expression</VAR> ;</CODE>
|
|
<DD>
|
|
<DT><CODE><VAR>symbol</VAR> += <VAR>expression</VAR> ;</CODE>
|
|
<DD>
|
|
<DT><CODE><VAR>symbol</VAR> -= <VAR>expression</VAR> ;</CODE>
|
|
<DD>
|
|
<DT><CODE><VAR>symbol</VAR> *= <VAR>expression</VAR> ;</CODE>
|
|
<DD>
|
|
<DT><CODE><VAR>symbol</VAR> /= <VAR>expression</VAR> ;</CODE>
|
|
<DD>
|
|
</DL>
|
|
|
|
<P>
|
|
Two things distinguish assignment from other operators in <CODE>ld</CODE>
|
|
expressions.
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
Assignment may only be used at the root of an expression;
|
|
<SAMP>`a=b+3;'</SAMP> is allowed, but <SAMP>`a+b=3;'</SAMP> is an error.
|
|
|
|
<A NAME="IDX225"></A>
|
|
<A NAME="IDX226"></A>
|
|
<LI>
|
|
|
|
You must place a trailing semicolon ("<KBD>;</KBD>") at the end of an
|
|
assignment statement.
|
|
</UL>
|
|
|
|
<P>
|
|
Assignment statements may appear:
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
as commands in their own right in an <CODE>ld</CODE> script; or
|
|
<LI>
|
|
|
|
as independent statements within a <CODE>SECTIONS</CODE> command; or
|
|
<LI>
|
|
|
|
as part of the contents of a section definition in a
|
|
<CODE>SECTIONS</CODE> command.
|
|
</UL>
|
|
|
|
<P>
|
|
The first two cases are equivalent in effect--both define a symbol with
|
|
an absolute address. The last case defines a symbol whose address is
|
|
relative to a particular section (see section <A HREF="ld.html#SEC17">Specifying Output Sections</A>).
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX227"></A>
|
|
<A NAME="IDX228"></A>
|
|
<A NAME="IDX229"></A>
|
|
When a linker expression is evaluated and assigned to a variable, it is
|
|
given either an absolute or a relocatable type. An absolute expression
|
|
type is one in which the symbol contains the value that it will have in
|
|
the output file; a relocatable expression type is one in which the
|
|
value is expressed as a fixed offset from the base of a section.
|
|
|
|
</P>
|
|
<P>
|
|
The type of the expression is controlled by its position in the script
|
|
file. A symbol assigned within a section definition is created relative
|
|
to the base of the section; a symbol assigned in any other place is
|
|
created as an absolute symbol. Since a symbol created within a
|
|
section definition is relative to the base of the section, it
|
|
will remain relocatable if relocatable output is requested. A symbol
|
|
may be created with an absolute value even when assigned to within a
|
|
section definition by using the absolute assignment function
|
|
<CODE>ABSOLUTE</CODE>. For example, to create an absolute symbol whose address
|
|
is the last byte of an output section named <CODE>.data</CODE>:
|
|
|
|
<PRE>
|
|
SECTIONS{ ...
|
|
.data :
|
|
{
|
|
*(.data)
|
|
_edata = ABSOLUTE(.) ;
|
|
}
|
|
... }
|
|
</PRE>
|
|
|
|
<P>
|
|
The linker tries to put off the evaluation of an assignment until all
|
|
the terms in the source expression are known (see section <A HREF="ld.html#SEC12">Evaluation</A>). For
|
|
instance, the sizes of sections cannot be known until after allocation,
|
|
so assignments dependent upon these are not performed until after
|
|
allocation. Some expressions, such as those depending upon the location
|
|
counter <EM>dot</EM>, <SAMP>`.'</SAMP> must be evaluated during allocation. If the
|
|
result of an expression is required, but the value is not available,
|
|
then an error results. For example, a script like the following
|
|
|
|
<PRE>
|
|
SECTIONS { ...
|
|
text 9+this_isnt_constant :
|
|
{ ...
|
|
}
|
|
... }
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX230"></A>
|
|
will cause the error message "<CODE>Non constant expression for initial
|
|
address</CODE>".
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX231"></A>
|
|
In some cases, it is desirable for a linker script to define a symbol
|
|
only if it is referenced, and only if it is not defined by any object
|
|
included in the link. For example, traditional linkers defined the
|
|
symbol <SAMP>`etext'</SAMP>. However, ANSI C requires that the user be able to
|
|
use <SAMP>`etext'</SAMP> as a function name without encountering an error.
|
|
The <CODE>PROVIDE</CODE> keyword may be used to define a symbol, such as
|
|
<SAMP>`etext'</SAMP>, only if it is referenced but not defined. The syntax is
|
|
<CODE>PROVIDE(<VAR>symbol</VAR> = <VAR>expression</VAR>)</CODE>.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC14" HREF="ld.html#TOC14">Arithmetic Functions</A></H3>
|
|
<P>
|
|
<A NAME="IDX232"></A>
|
|
The command language includes a number of built-in
|
|
functions for use in link script expressions.
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>ABSOLUTE(<VAR>exp</VAR>)</CODE>
|
|
<DD>
|
|
<A NAME="IDX233"></A>
|
|
<A NAME="IDX234"></A>
|
|
|
|
Return the absolute (non-relocatable, as opposed to non-negative) value
|
|
of the expression <VAR>exp</VAR>. Primarily useful to assign an absolute
|
|
value to a symbol within a section definition, where symbol values are
|
|
normally section-relative.
|
|
|
|
<A NAME="IDX235"></A>
|
|
<A NAME="IDX236"></A>
|
|
<DT><CODE>ADDR(<VAR>section</VAR>)</CODE>
|
|
<DD>
|
|
Return the absolute address of the named <VAR>section</VAR>. Your script must
|
|
previously have defined the location of that section. In the following
|
|
example, <CODE>symbol_1</CODE> and <CODE>symbol_2</CODE> are assigned identical
|
|
values:
|
|
|
|
<PRE>
|
|
SECTIONS{ ...
|
|
.output1 :
|
|
{
|
|
start_of_output_1 = ABSOLUTE(.);
|
|
...
|
|
}
|
|
.output :
|
|
{
|
|
symbol_1 = ADDR(.output1);
|
|
symbol_2 = start_of_output_1;
|
|
}
|
|
... }
|
|
</PRE>
|
|
|
|
<A NAME="IDX237"></A>
|
|
<A NAME="IDX238"></A>
|
|
<DT><CODE>LOADADDR(<VAR>section</VAR>)</CODE>
|
|
<DD>
|
|
Return the absolute load address of the named <VAR>section</VAR>. This is
|
|
normally the same as <CODE>ADDR</CODE>, but it may be different if the
|
|
<CODE>AT</CODE> keyword is used in the section definition (see section <A HREF="ld.html#SEC21">Optional Section Attributes</A>).
|
|
|
|
<A NAME="IDX239"></A>
|
|
<A NAME="IDX240"></A>
|
|
<DT><CODE>ALIGN(<VAR>exp</VAR>)</CODE>
|
|
<DD>
|
|
Return the result of the current location counter (<CODE>.</CODE>) aligned to
|
|
the next <VAR>exp</VAR> boundary. <VAR>exp</VAR> must be an expression whose
|
|
value is a power of two. This is equivalent to
|
|
|
|
<PRE>
|
|
(. + <VAR>exp</VAR> - 1) & ~(<VAR>exp</VAR> - 1)
|
|
</PRE>
|
|
|
|
<CODE>ALIGN</CODE> doesn't change the value of the location counter--it just
|
|
does arithmetic on it. As an example, to align the output <CODE>.data</CODE>
|
|
section to the next <CODE>0x2000</CODE> byte boundary after the preceding
|
|
section and to set a variable within the section to the next
|
|
<CODE>0x8000</CODE> boundary after the input sections:
|
|
|
|
<PRE>
|
|
SECTIONS{ ...
|
|
.data ALIGN(0x2000): {
|
|
*(.data)
|
|
variable = ALIGN(0x8000);
|
|
}
|
|
... }
|
|
</PRE>
|
|
|
|
The first use of <CODE>ALIGN</CODE> in this example specifies the location of
|
|
a section because it is used as the optional <VAR>start</VAR> attribute of a
|
|
section definition (see section <A HREF="ld.html#SEC21">Optional Section Attributes</A>). The second use simply
|
|
defines the value of a variable.
|
|
|
|
The built-in <CODE>NEXT</CODE> is closely related to <CODE>ALIGN</CODE>.
|
|
|
|
<A NAME="IDX241"></A>
|
|
<A NAME="IDX242"></A>
|
|
<DT><CODE>DEFINED(<VAR>symbol</VAR>)</CODE>
|
|
<DD>
|
|
Return 1 if <VAR>symbol</VAR> is in the linker global symbol table and is
|
|
defined, otherwise return 0. You can use this function to provide default
|
|
values for symbols. For example, the following command-file fragment shows how
|
|
to set a global symbol <CODE>begin</CODE> to the first location in the
|
|
<CODE>.text</CODE> section--but if a symbol called <CODE>begin</CODE> already
|
|
existed, its value is preserved:
|
|
|
|
|
|
<PRE>
|
|
SECTIONS{ ...
|
|
.text : {
|
|
begin = DEFINED(begin) ? begin : . ;
|
|
...
|
|
}
|
|
... }
|
|
</PRE>
|
|
|
|
<A NAME="IDX243"></A>
|
|
<A NAME="IDX244"></A>
|
|
<DT><CODE>NEXT(<VAR>exp</VAR>)</CODE>
|
|
<DD>
|
|
Return the next unallocated address that is a multiple of <VAR>exp</VAR>.
|
|
This function is closely related to <CODE>ALIGN(<VAR>exp</VAR>)</CODE>; unless you
|
|
use the <CODE>MEMORY</CODE> command to define discontinuous memory for the
|
|
output file, the two functions are equivalent.
|
|
|
|
<A NAME="IDX245"></A>
|
|
<A NAME="IDX246"></A>
|
|
<DT><CODE>SIZEOF(<VAR>section</VAR>)</CODE>
|
|
<DD>
|
|
Return the size in bytes of the named <VAR>section</VAR>, if that section has
|
|
been allocated. In the following example, <CODE>symbol_1</CODE> and
|
|
<CODE>symbol_2</CODE> are assigned identical values:
|
|
|
|
<PRE>
|
|
SECTIONS{ ...
|
|
.output {
|
|
.start = . ;
|
|
...
|
|
.end = . ;
|
|
}
|
|
symbol_1 = .end - .start ;
|
|
symbol_2 = SIZEOF(.output);
|
|
... }
|
|
</PRE>
|
|
|
|
<A NAME="IDX247"></A>
|
|
<A NAME="IDX248"></A>
|
|
<A NAME="IDX249"></A>
|
|
<DT><CODE>SIZEOF_HEADERS</CODE>
|
|
<DD>
|
|
<DT><CODE>sizeof_headers</CODE>
|
|
<DD>
|
|
Return the size in bytes of the output file's headers. You can use this number
|
|
as the start address of the first section, if you choose, to facilitate
|
|
paging.
|
|
|
|
<A NAME="IDX250"></A>
|
|
<DT><CODE>MAX(<VAR>exp1</VAR>, <VAR>exp2</VAR>)</CODE>
|
|
<DD>
|
|
Returns the maximum of <VAR>exp1</VAR> and <VAR>exp2</VAR>.
|
|
|
|
<A NAME="IDX251"></A>
|
|
<DT><CODE>MIN(<VAR>exp1</VAR>, <VAR>exp2</VAR>)</CODE>
|
|
<DD>
|
|
Returns the minimum of <VAR>exp1</VAR> and <VAR>exp2</VAR>.
|
|
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC15" HREF="ld.html#TOC15">Semicolons</A></H3>
|
|
|
|
<P>
|
|
Semicolons ("<KBD>;</KBD>") are required in the following places. In all
|
|
other places they can appear for aesthetic reasons but are otherwise ignored.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>Assignment</CODE>
|
|
<DD>
|
|
Semicolons must appear at the end of assignment expressions.
|
|
See section <A HREF="ld.html#SEC13">Assignment: Defining Symbols</A>
|
|
|
|
<DT><CODE>PHDRS</CODE>
|
|
<DD>
|
|
Semicolons must appear at the end of a <CODE>PHDRS</CODE> statement.
|
|
See section <A HREF="ld.html#SEC23">ELF Program Headers</A>
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC16" HREF="ld.html#TOC16">Memory Layout</A></H2>
|
|
<P>
|
|
<A NAME="IDX252"></A>
|
|
<A NAME="IDX253"></A>
|
|
<A NAME="IDX254"></A>
|
|
<A NAME="IDX255"></A>
|
|
The linker's default configuration permits allocation of all available memory.
|
|
You can override this configuration by using the <CODE>MEMORY</CODE> command. The
|
|
<CODE>MEMORY</CODE> command describes the location and size of blocks of
|
|
memory in the target. By using it carefully, you can describe which
|
|
memory regions may be used by the linker, and which memory regions it
|
|
must avoid. The linker does not shuffle sections to fit into the
|
|
available regions, but does move the requested sections into the correct
|
|
regions and issue errors when the regions become too full.
|
|
|
|
</P>
|
|
<P>
|
|
A command file may contain at most one use of the <CODE>MEMORY</CODE>
|
|
command; however, you can define as many blocks of memory within it as
|
|
you wish. The syntax is:
|
|
|
|
|
|
<PRE>
|
|
MEMORY
|
|
{
|
|
<VAR>name</VAR> (<VAR>attr</VAR>) : ORIGIN = <VAR>origin</VAR>, LENGTH = <VAR>len</VAR>
|
|
...
|
|
}
|
|
</PRE>
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE><VAR>name</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX256"></A>
|
|
|
|
is a name used internally by the linker to refer to the region. Any
|
|
symbol name may be used. The region names are stored in a separate
|
|
name space, and will not conflict with symbols, file names or section
|
|
names. Use distinct names to specify multiple regions.
|
|
|
|
<A NAME="IDX257"></A>
|
|
<DT><CODE>(<VAR>attr</VAR>)</CODE>
|
|
<DD>
|
|
is an optional list of attributes that specify whether to use a
|
|
particular memory to place sections that are not listed in the linker
|
|
script. Valid attribute lists must be made up of the characters
|
|
"<CODE>ALIRWX</CODE>" that match section attributes. If you omit the
|
|
attribute list, you may omit the parentheses around it as well. The
|
|
attributes currently supported are:
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><SAMP>`<CODE>Letter</CODE>'</SAMP>
|
|
<DD>
|
|
<CODE>Section Attribute</CODE>
|
|
|
|
<DT><SAMP>`<CODE>R</CODE>'</SAMP>
|
|
<DD>
|
|
Read-only sections.
|
|
|
|
<DT><SAMP>`<CODE>W</CODE>'</SAMP>
|
|
<DD>
|
|
Read/write sections.
|
|
|
|
<DT><SAMP>`<CODE>X</CODE>'</SAMP>
|
|
<DD>
|
|
Sections containing executable code.
|
|
|
|
<DT><SAMP>`<CODE>A</CODE>'</SAMP>
|
|
<DD>
|
|
Allocated sections.
|
|
|
|
<DT><SAMP>`<CODE>I</CODE>'</SAMP>
|
|
<DD>
|
|
Initialized sections.
|
|
|
|
<DT><SAMP>`<CODE>L</CODE>'</SAMP>
|
|
<DD>
|
|
Same as <CODE>I</CODE>.
|
|
|
|
<DT><SAMP>`<CODE>!</CODE>'</SAMP>
|
|
<DD>
|
|
Invert the sense of any of the following attributes.
|
|
</DL>
|
|
|
|
<A NAME="IDX258"></A>
|
|
<A NAME="IDX259"></A>
|
|
<A NAME="IDX260"></A>
|
|
<DT><CODE><VAR>origin</VAR></CODE>
|
|
<DD>
|
|
is the start address of the region in physical memory. It is
|
|
an expression that must evaluate to a constant before
|
|
memory allocation is performed. The keyword <CODE>ORIGIN</CODE> may be
|
|
abbreviated to <CODE>org</CODE> or <CODE>o</CODE> (but not, for example, <SAMP>`ORG'</SAMP>).
|
|
|
|
<A NAME="IDX261"></A>
|
|
<A NAME="IDX262"></A>
|
|
<A NAME="IDX263"></A>
|
|
<DT><CODE><VAR>len</VAR></CODE>
|
|
<DD>
|
|
is the size in bytes of the region (an expression).
|
|
The keyword <CODE>LENGTH</CODE> may be abbreviated to <CODE>len</CODE> or <CODE>l</CODE>.
|
|
</DL>
|
|
|
|
<P>
|
|
For example, to specify that memory has two regions available for
|
|
allocation--one starting at 0 for 256 kilobytes, and the other starting
|
|
at <CODE>0x40000000</CODE> for four megabytes. The <CODE>rom</CODE> memory region
|
|
will get all sections without an explicit memory register that are
|
|
either read-only or contain code, while the <CODE>ram</CODE> memory region
|
|
will get the sections.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
MEMORY
|
|
{
|
|
rom (rx) : ORIGIN = 0, LENGTH = 256K
|
|
ram (!rx) : org = 0x40000000, l = 4M
|
|
}
|
|
</PRE>
|
|
|
|
<P>
|
|
Once you have defined a region of memory named <VAR>mem</VAR>, you can direct
|
|
specific output sections there by using a command ending in
|
|
<SAMP>`><VAR>mem</VAR>'</SAMP> within the <CODE>SECTIONS</CODE> command (see section <A HREF="ld.html#SEC21">Optional Section Attributes</A>). If the combined output sections directed to a region are too
|
|
big for the region, the linker will issue an error message.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC17" HREF="ld.html#TOC17">Specifying Output Sections</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX264"></A>
|
|
The <CODE>SECTIONS</CODE> command controls exactly where input sections are
|
|
placed into output sections, their order in the output file, and to
|
|
which output sections they are allocated.
|
|
|
|
</P>
|
|
<P>
|
|
You may use at most one <CODE>SECTIONS</CODE> command in a script file,
|
|
but you can have as many statements within it as you wish. Statements
|
|
within the <CODE>SECTIONS</CODE> command can do one of three things:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
define the entry point;
|
|
|
|
<LI>
|
|
|
|
assign a value to a symbol;
|
|
|
|
<LI>
|
|
|
|
describe the placement of a named output section, and which input
|
|
sections go into it.
|
|
</UL>
|
|
|
|
<P>
|
|
You can also use the first two operations--defining the entry point and
|
|
defining symbols--outside the <CODE>SECTIONS</CODE> command: see section <A HREF="ld.html#SEC24">The Entry Point</A>, and section <A HREF="ld.html#SEC13">Assignment: Defining Symbols</A>. They are permitted here as well for
|
|
your convenience in reading the script, so that symbols and the entry
|
|
point can be defined at meaningful points in your output-file layout.
|
|
|
|
</P>
|
|
<P>
|
|
If you do not use a <CODE>SECTIONS</CODE> command, the linker places each input
|
|
section into an identically named output section in the order that the
|
|
sections are first encountered in the input files. If all input sections
|
|
are present in the first file, for example, the order of sections in the
|
|
output file will match the order in the first input file.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC18" HREF="ld.html#TOC18">Section Definitions</A></H3>
|
|
<P>
|
|
<A NAME="IDX265"></A>
|
|
The most frequently used statement in the <CODE>SECTIONS</CODE> command is
|
|
the <EM>section definition</EM>, which specifies the
|
|
properties of an output section: its location, alignment, contents,
|
|
fill pattern, and target memory region. Most of
|
|
these specifications are optional; the simplest form of a section
|
|
definition is
|
|
|
|
<PRE>
|
|
SECTIONS { ...
|
|
<VAR>secname</VAR> : {
|
|
<VAR>contents</VAR>
|
|
}
|
|
... }
|
|
</PRE>
|
|
|
|
<P>
|
|
<A NAME="IDX266"></A>
|
|
<VAR>secname</VAR> is the name of the output section, and <VAR>contents</VAR> a
|
|
specification of what goes there--for example, a list of input files or
|
|
sections of input files (see section <A HREF="ld.html#SEC19">Section Placement</A>). The whitespace
|
|
around <VAR>secname</VAR> is required, so that the section name is
|
|
unambiguous. The other whitespace shown is optional. You do need the
|
|
colon <SAMP>`:'</SAMP> and the braces <SAMP>`{}'</SAMP>, however.
|
|
|
|
</P>
|
|
<P>
|
|
<VAR>secname</VAR> must meet the constraints of your output format. In
|
|
formats which only support a limited number of sections, such as
|
|
<CODE>a.out</CODE>, the name must be one of the names supported by the format
|
|
(<CODE>a.out</CODE>, for example, allows only <CODE>.text</CODE>, <CODE>.data</CODE> or
|
|
<CODE>.bss</CODE>). If the output format supports any number of sections, but
|
|
with numbers and not names (as is the case for Oasys), the name should be
|
|
supplied as a quoted numeric string. A section name may consist of any
|
|
sequence of characters, but any name which does not conform to the standard
|
|
<CODE>ld</CODE> symbol name syntax must be quoted.
|
|
See section <A HREF="ld.html#SEC9">Symbol Names</A>.
|
|
|
|
</P>
|
|
<P>
|
|
The special <VAR>secname</VAR> <SAMP>`/DISCARD/'</SAMP> may be used to discard input
|
|
sections. Any sections which are assigned to an output section named
|
|
<SAMP>`/DISCARD/'</SAMP> are not included in the final link output.
|
|
|
|
</P>
|
|
<P>
|
|
The linker will not create output sections which do not have any
|
|
contents. This is for convenience when referring to input sections that
|
|
may or may not exist. For example,
|
|
|
|
<PRE>
|
|
.foo { *(.foo) }
|
|
</PRE>
|
|
|
|
<P>
|
|
will only create a <SAMP>`.foo'</SAMP> section in the output file if there is a
|
|
<SAMP>`.foo'</SAMP> section in at least one input file.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC19" HREF="ld.html#TOC19">Section Placement</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX267"></A>
|
|
In a section definition, you can specify the contents of an output
|
|
section by listing particular input files, by listing particular
|
|
input-file sections, or by a combination of the two. You can also place
|
|
arbitrary data in the section, and define symbols relative to the
|
|
beginning of the section.
|
|
|
|
</P>
|
|
<P>
|
|
The <VAR>contents</VAR> of a section definition may include any of the
|
|
following kinds of statement. You can include as many of these as you
|
|
like in a single section definition, separated from one another by
|
|
whitespace.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE><VAR>filename</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX268"></A>
|
|
<A NAME="IDX269"></A>
|
|
<A NAME="IDX270"></A>
|
|
|
|
You may simply name a particular input file to be placed in the current
|
|
output section; <EM>all</EM> sections from that file are placed in the
|
|
current section definition. If the file name has already been mentioned
|
|
in another section definition, with an explicit section name list, then
|
|
only those sections which have not yet been allocated are used.
|
|
|
|
To specify a list of particular files by name:
|
|
|
|
<PRE>
|
|
.data : { afile.o bfile.o cfile.o }
|
|
</PRE>
|
|
|
|
The example also illustrates that multiple statements can be included in
|
|
the contents of a section definition, since each file name is a separate
|
|
statement.
|
|
|
|
<A NAME="IDX271"></A>
|
|
<A NAME="IDX272"></A>
|
|
<DT><CODE><VAR>filename</VAR>( <VAR>section</VAR> )</CODE>
|
|
<DD>
|
|
<DT><CODE><VAR>filename</VAR>( <VAR>section</VAR> , <VAR>section</VAR>, ... )</CODE>
|
|
<DD>
|
|
<DT><CODE><VAR>filename</VAR>( <VAR>section</VAR> <VAR>section</VAR> ... )</CODE>
|
|
<DD>
|
|
You can name one or more sections from your input files, for insertion
|
|
in the current output section. If you wish to specify a list of
|
|
input-file sections inside the parentheses, separate the section names
|
|
with whitespace.
|
|
|
|
<A NAME="IDX273"></A>
|
|
<A NAME="IDX274"></A>
|
|
<DT><CODE>* (<VAR>section</VAR>)</CODE>
|
|
<DD>
|
|
<DT><CODE>* (<VAR>section</VAR>, <VAR>section</VAR>, ...)</CODE>
|
|
<DD>
|
|
<DT><CODE>* (<VAR>section</VAR> <VAR>section</VAR> ...)</CODE>
|
|
<DD>
|
|
Instead of explicitly naming particular input files in a link control
|
|
script, you can refer to <EM>all</EM> files from the <CODE>ld</CODE> command
|
|
line: use <SAMP>`*'</SAMP> instead of a particular file name before the
|
|
parenthesized input-file section list.
|
|
|
|
If you have already explicitly included some files by name, <SAMP>`*'</SAMP>
|
|
refers to all <EM>remaining</EM> files--those whose places in the output
|
|
file have not yet been defined.
|
|
|
|
For example, to copy sections <CODE>1</CODE> through <CODE>4</CODE> from an Oasys file
|
|
into the <CODE>.text</CODE> section of an <CODE>a.out</CODE> file, and sections <CODE>13</CODE>
|
|
and <CODE>14</CODE> into the <CODE>.data</CODE> section:
|
|
|
|
<PRE>
|
|
SECTIONS {
|
|
.text :{
|
|
*("1" "2" "3" "4")
|
|
}
|
|
|
|
.data :{
|
|
*("13" "14")
|
|
}
|
|
}
|
|
</PRE>
|
|
|
|
<A NAME="IDX275"></A>
|
|
<SAMP>`[ <VAR>section</VAR> ... ]'</SAMP> used to be accepted as an alternate way
|
|
to specify named sections from all unallocated input files. Because
|
|
some operating systems (VMS) allow brackets in file names, that notation
|
|
is no longer supported.
|
|
|
|
<A NAME="IDX276"></A>
|
|
<A NAME="IDX277"></A>
|
|
<A NAME="IDX278"></A>
|
|
<DT><CODE><VAR>filename</VAR><CODE>( COMMON )</CODE></CODE>
|
|
<DD>
|
|
<DT><CODE>*( COMMON )</CODE>
|
|
<DD>
|
|
Specify where in your output file to place uninitialized data
|
|
with this notation. <CODE>*(COMMON)</CODE> by itself refers to all
|
|
uninitialized data from all input files (so far as it is not yet
|
|
allocated); <VAR>filename</VAR><CODE>(COMMON)</CODE> refers to uninitialized data
|
|
from a particular file. Both are special cases of the general
|
|
mechanisms for specifying where to place input-file sections:
|
|
<CODE>ld</CODE> permits you to refer to uninitialized data as if it
|
|
were in an input-file section named <CODE>COMMON</CODE>, regardless of the
|
|
input file's format.
|
|
</DL>
|
|
|
|
<P>
|
|
In any place where you may use a specific file or section name, you may
|
|
also use a wildcard pattern. The linker handles wildcards much as the
|
|
Unix shell does. A <SAMP>`*'</SAMP> character matches any number of characters.
|
|
A <SAMP>`?'</SAMP> character matches any single character. The sequence
|
|
<SAMP>`[<VAR>chars</VAR>]'</SAMP> will match a single instance of any of the
|
|
<VAR>chars</VAR>; the <SAMP>`-'</SAMP> character may be used to specify a range of
|
|
characters, as in <SAMP>`[a-z]'</SAMP> to match any lower case letter. A
|
|
<SAMP>`\'</SAMP> character may be used to quote the following character.
|
|
|
|
</P>
|
|
<P>
|
|
When a file name is matched with a wildcard, the wildcard characters
|
|
will not match a <SAMP>`/'</SAMP> character (used to separate directory names on
|
|
Unix). A pattern consisting of a single <SAMP>`*'</SAMP> character is an
|
|
exception; it will always match any file name. In a section name, the
|
|
wildcard characters will match a <SAMP>`/'</SAMP> character.
|
|
|
|
</P>
|
|
<P>
|
|
Wildcards only match files which are explicitly specified on the command
|
|
line. The linker does not search directories to expand wildcards.
|
|
However, if you specify a simple file name--a name with no wildcard
|
|
characters--in a linker script, and the file name is not also specified
|
|
on the command line, the linker will attempt to open the file as though
|
|
it appeared on the command line.
|
|
|
|
</P>
|
|
<P>
|
|
In the following example, the command script arranges the output file
|
|
into three consecutive sections, named <CODE>.text</CODE>, <CODE>.data</CODE>, and
|
|
<CODE>.bss</CODE>, taking the input for each from the correspondingly named
|
|
sections of all the input files:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
SECTIONS {
|
|
.text : { *(.text) }
|
|
.data : { *(.data) }
|
|
.bss : { *(.bss) *(COMMON) }
|
|
}
|
|
</PRE>
|
|
|
|
<P>
|
|
The following example reads all of the sections from file <CODE>all.o</CODE>
|
|
and places them at the start of output section <CODE>outputa</CODE> which
|
|
starts at location <CODE>0x10000</CODE>. All of section <CODE>.input1</CODE> from
|
|
file <CODE>foo.o</CODE> follows immediately, in the same output section. All
|
|
of section <CODE>.input2</CODE> from <CODE>foo.o</CODE> goes into output section
|
|
<CODE>outputb</CODE>, followed by section <CODE>.input1</CODE> from <CODE>foo1.o</CODE>.
|
|
All of the remaining <CODE>.input1</CODE> and <CODE>.input2</CODE> sections from any
|
|
files are written to output section <CODE>outputc</CODE>.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
SECTIONS {
|
|
outputa 0x10000 :
|
|
{
|
|
all.o
|
|
foo.o (.input1)
|
|
}
|
|
outputb :
|
|
{
|
|
foo.o (.input2)
|
|
foo1.o (.input1)
|
|
}
|
|
outputc :
|
|
{
|
|
*(.input1)
|
|
*(.input2)
|
|
}
|
|
}
|
|
</PRE>
|
|
|
|
<P>
|
|
This example shows how wildcard patterns might be used to partition
|
|
files. All <CODE>.text</CODE> sections are placed in <CODE>.text</CODE>, and all
|
|
<CODE>.bss</CODE> sections are placed in <CODE>.bss</CODE>. For all files beginning
|
|
with an upper case character, the <CODE>.data</CODE> section is placed into
|
|
<CODE>.DATA</CODE>; for all other files, the <CODE>.data</CODE> section is placed
|
|
into <CODE>.data</CODE>.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
SECTIONS {
|
|
.text : { *(.text) }
|
|
.DATA : { [A-Z]*(.data) }
|
|
.data : { *(.data) }
|
|
.bss : { *(.bss) }
|
|
}
|
|
</PRE>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC20" HREF="ld.html#TOC20">Section Data Expressions</A></H3>
|
|
|
|
<P>
|
|
<A NAME="IDX279"></A>
|
|
The foregoing statements arrange, in your output file, data originating
|
|
from your input files. You can also place data directly in an output
|
|
section from the link command script. Most of these additional
|
|
statements involve expressions (see section <A HREF="ld.html#SEC7">Expressions</A>). Although these
|
|
statements are shown separately here for ease of presentation, no such
|
|
segregation is needed within a section definition in the <CODE>SECTIONS</CODE>
|
|
command; you can intermix them freely with any of the statements we've
|
|
just described.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>CREATE_OBJECT_SYMBOLS</CODE>
|
|
<DD>
|
|
<A NAME="IDX280"></A>
|
|
<A NAME="IDX281"></A>
|
|
<A NAME="IDX282"></A>
|
|
|
|
Create a symbol for each input file
|
|
in the current section, set to the address of the first byte of
|
|
data written from that input file. For instance, with <CODE>a.out</CODE>
|
|
files it is conventional to have a symbol for each input file. You can
|
|
accomplish this by defining the output <CODE>.text</CODE> section as follows:
|
|
|
|
<PRE>
|
|
SECTIONS {
|
|
.text 0x2020 :
|
|
{
|
|
CREATE_OBJECT_SYMBOLS
|
|
*(.text)
|
|
_etext = ALIGN(0x2000);
|
|
}
|
|
...
|
|
}
|
|
</PRE>
|
|
|
|
If <CODE>sample.ld</CODE> is a file containing this script, and <CODE>a.o</CODE>,
|
|
<CODE>b.o</CODE>, <CODE>c.o</CODE>, and <CODE>d.o</CODE> are four input files with
|
|
contents like the following---
|
|
|
|
<PRE>
|
|
/* a.c */
|
|
|
|
afunction() { }
|
|
int adata=1;
|
|
int abss;
|
|
</PRE>
|
|
|
|
<SAMP>`ld -M -T sample.ld a.o b.o c.o d.o'</SAMP> would create a map like this,
|
|
containing symbols matching the object file names:
|
|
|
|
<PRE>
|
|
00000000 A __DYNAMIC
|
|
00004020 B _abss
|
|
00004000 D _adata
|
|
00002020 T _afunction
|
|
00004024 B _bbss
|
|
00004008 D _bdata
|
|
00002038 T _bfunction
|
|
00004028 B _cbss
|
|
00004010 D _cdata
|
|
00002050 T _cfunction
|
|
0000402c B _dbss
|
|
00004018 D _ddata
|
|
00002068 T _dfunction
|
|
00004020 D _edata
|
|
00004030 B _end
|
|
00004000 T _etext
|
|
00002020 t a.o
|
|
00002038 t b.o
|
|
00002050 t c.o
|
|
00002068 t d.o
|
|
</PRE>
|
|
|
|
<A NAME="IDX283"></A>
|
|
<A NAME="IDX284"></A>
|
|
<DT><CODE><VAR>symbol</VAR> = <VAR>expression</VAR> ;</CODE>
|
|
<DD>
|
|
<DT><CODE><VAR>symbol</VAR> <VAR>f</VAR>= <VAR>expression</VAR> ;</CODE>
|
|
<DD>
|
|
<VAR>symbol</VAR> is any symbol name (see section <A HREF="ld.html#SEC9">Symbol Names</A>). "<VAR>f</VAR>="
|
|
refers to any of the operators <CODE>&= += -= *= /=</CODE> which combine
|
|
arithmetic and assignment.
|
|
|
|
<A NAME="IDX285"></A>
|
|
When you assign a value to a symbol within a particular section
|
|
definition, the value is relative to the beginning of the section
|
|
(see section <A HREF="ld.html#SEC13">Assignment: Defining Symbols</A>). If you write
|
|
|
|
|
|
<PRE>
|
|
SECTIONS {
|
|
abs = 14 ;
|
|
...
|
|
.data : { ... rel = 14 ; ... }
|
|
abs2 = 14 + ADDR(.data);
|
|
...
|
|
}
|
|
</PRE>
|
|
|
|
<CODE>abs</CODE> and <CODE>rel</CODE> do not have the same value; <CODE>rel</CODE> has the
|
|
same value as <CODE>abs2</CODE>.
|
|
|
|
<A NAME="IDX286"></A>
|
|
<A NAME="IDX287"></A>
|
|
<A NAME="IDX288"></A>
|
|
<A NAME="IDX289"></A>
|
|
<A NAME="IDX290"></A>
|
|
<A NAME="IDX291"></A>
|
|
<DT><CODE>BYTE(<VAR>expression</VAR>)</CODE>
|
|
<DD>
|
|
<DT><CODE>SHORT(<VAR>expression</VAR>)</CODE>
|
|
<DD>
|
|
<DT><CODE>LONG(<VAR>expression</VAR>)</CODE>
|
|
<DD>
|
|
<DT><CODE>QUAD(<VAR>expression</VAR>)</CODE>
|
|
<DD>
|
|
<DT><CODE>SQUAD(<VAR>expression</VAR>)</CODE>
|
|
<DD>
|
|
By including one of these four statements in a section definition, you
|
|
can explicitly place one, two, four, eight unsigned, or eight signed
|
|
bytes (respectively) at the current address of that section. When using
|
|
a 64 bit host or target, <CODE>QUAD</CODE> and <CODE>SQUAD</CODE> are the same.
|
|
When both host and target are 32 bits, <CODE>QUAD</CODE> uses an unsigned 32
|
|
bit value, and <CODE>SQUAD</CODE> sign extends the value. Both will use the
|
|
correct endianness when writing out the value.
|
|
|
|
Multiple-byte quantities are represented in whatever byte order is
|
|
appropriate for the output file format (see section <A HREF="ld.html#SEC30">BFD</A>).
|
|
|
|
<A NAME="IDX292"></A>
|
|
<A NAME="IDX293"></A>
|
|
<A NAME="IDX294"></A>
|
|
<DT><CODE>FILL(<VAR>expression</VAR>)</CODE>
|
|
<DD>
|
|
Specify the "fill pattern" for the current section. Any otherwise
|
|
unspecified regions of memory within the section (for example, regions
|
|
you skip over by assigning a new value to the location counter <SAMP>`.'</SAMP>)
|
|
are filled with the two least significant bytes from the
|
|
<VAR>expression</VAR> argument. A <CODE>FILL</CODE> statement covers memory
|
|
locations <EM>after</EM> the point it occurs in the section definition; by
|
|
including more than one <CODE>FILL</CODE> statement, you can have different
|
|
fill patterns in different parts of an output section.
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC21" HREF="ld.html#TOC21">Optional Section Attributes</A></H3>
|
|
<P>
|
|
<A NAME="IDX295"></A>
|
|
Here is the full syntax of a section definition, including all the
|
|
optional portions:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
SECTIONS {
|
|
...
|
|
<VAR>secname</VAR> <VAR>start</VAR> BLOCK(<VAR>align</VAR>) (NOLOAD) : AT ( <VAR>ldadr</VAR> )
|
|
{ <VAR>contents</VAR> } ><VAR>region</VAR> :<VAR>phdr</VAR> =<VAR>fill</VAR>
|
|
...
|
|
}
|
|
</PRE>
|
|
|
|
<P>
|
|
<VAR>secname</VAR> and <VAR>contents</VAR> are required. See section <A HREF="ld.html#SEC18">Section Definitions</A>, and section <A HREF="ld.html#SEC19">Section Placement</A>, for details on
|
|
<VAR>contents</VAR>. The remaining elements---<VAR>start</VAR>,
|
|
<CODE>BLOCK(<VAR>align)</VAR></CODE>, <CODE>(NOLOAD)</CODE>, <CODE>AT ( <VAR>ldadr</VAR> )</CODE>,
|
|
<CODE>><VAR>region</VAR></CODE>, <CODE>:<VAR>phdr</VAR></CODE>, and <CODE>=<VAR>fill</VAR></CODE>---are
|
|
all optional.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE><VAR>start</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX296"></A>
|
|
<A NAME="IDX297"></A>
|
|
<A NAME="IDX298"></A>
|
|
|
|
You can force the output section to be loaded at a specified address by
|
|
specifying <VAR>start</VAR> immediately following the section name.
|
|
<VAR>start</VAR> can be represented as any expression. The following
|
|
example generates section <VAR>output</VAR> at location
|
|
<CODE>0x40000000</CODE>:
|
|
|
|
|
|
<PRE>
|
|
SECTIONS {
|
|
...
|
|
output 0x40000000: {
|
|
...
|
|
}
|
|
...
|
|
}
|
|
</PRE>
|
|
|
|
<A NAME="IDX299"></A>
|
|
<A NAME="IDX300"></A>
|
|
<A NAME="IDX301"></A>
|
|
<DT><CODE>BLOCK(<VAR>align</VAR>)</CODE>
|
|
<DD>
|
|
You can include <CODE>BLOCK()</CODE> specification to advance
|
|
the location counter <CODE>.</CODE> prior to the beginning of the section, so
|
|
that the section will begin at the specified alignment. <VAR>align</VAR> is
|
|
an expression.
|
|
|
|
<A NAME="IDX302"></A>
|
|
<A NAME="IDX303"></A>
|
|
<A NAME="IDX304"></A>
|
|
<DT><CODE>(NOLOAD)</CODE>
|
|
<DD>
|
|
The <SAMP>`(NOLOAD)'</SAMP> directive will mark a section to not be loaded at
|
|
run time. The linker will process the section normally, but will mark
|
|
it so that a program loader will not load it into memory. For example,
|
|
in the script sample below, the <CODE>ROM</CODE> section is addressed at
|
|
memory location <SAMP>`0'</SAMP> and does not need to be loaded when the program
|
|
is run. The contents of the <CODE>ROM</CODE> section will appear in the
|
|
linker output file as usual.
|
|
|
|
|
|
<PRE>
|
|
SECTIONS {
|
|
ROM 0 (NOLOAD) : { ... }
|
|
...
|
|
}
|
|
</PRE>
|
|
|
|
<A NAME="IDX305"></A>
|
|
<A NAME="IDX306"></A>
|
|
<A NAME="IDX307"></A>
|
|
<DT><CODE>AT ( <VAR>ldadr</VAR> )</CODE>
|
|
<DD>
|
|
The expression <VAR>ldadr</VAR> that follows the <CODE>AT</CODE> keyword specifies
|
|
the load address of the section. The default (if you do not use the
|
|
<CODE>AT</CODE> keyword) is to make the load address the same as the
|
|
relocation address. This feature is designed to make it easy to build a
|
|
ROM image. For example, this <CODE>SECTIONS</CODE> definition creates two
|
|
output sections: one called <SAMP>`.text'</SAMP>, which starts at <CODE>0x1000</CODE>,
|
|
and one called <SAMP>`.mdata'</SAMP>, which is loaded at the end of the
|
|
<SAMP>`.text'</SAMP> section even though its relocation address is
|
|
<CODE>0x2000</CODE>. The symbol <CODE>_data</CODE> is defined with the value
|
|
<CODE>0x2000</CODE>:
|
|
|
|
|
|
<PRE>
|
|
SECTIONS
|
|
{
|
|
.text 0x1000 : { *(.text) _etext = . ; }
|
|
.mdata 0x2000 :
|
|
AT ( ADDR(.text) + SIZEOF ( .text ) )
|
|
{ _data = . ; *(.data); _edata = . ; }
|
|
.bss 0x3000 :
|
|
{ _bstart = . ; *(.bss) *(COMMON) ; _bend = . ;}
|
|
}
|
|
</PRE>
|
|
|
|
The run-time initialization code (for C programs, usually <CODE>crt0</CODE>)
|
|
for use with a ROM generated this way has to include something like
|
|
the following, to copy the initialized data from the ROM image to its runtime
|
|
address:
|
|
|
|
|
|
<PRE>
|
|
char *src = _etext;
|
|
char *dst = _data;
|
|
|
|
/* ROM has data at end of text; copy it. */
|
|
while (dst < _edata) {
|
|
*dst++ = *src++;
|
|
}
|
|
|
|
/* Zero bss */
|
|
for (dst = _bstart; dst< _bend; dst++)
|
|
*dst = 0;
|
|
</PRE>
|
|
|
|
<A NAME="IDX308"></A>
|
|
<A NAME="IDX309"></A>
|
|
<A NAME="IDX310"></A>
|
|
<DT><CODE>><VAR>region</VAR></CODE>
|
|
<DD>
|
|
Assign this section to a previously defined region of memory.
|
|
See section <A HREF="ld.html#SEC16">Memory Layout</A>.
|
|
|
|
<A NAME="IDX311"></A>
|
|
<A NAME="IDX312"></A>
|
|
<A NAME="IDX313"></A>
|
|
<DT><CODE>:<VAR>phdr</VAR></CODE>
|
|
<DD>
|
|
Assign this section to a segment described by a program header.
|
|
See section <A HREF="ld.html#SEC23">ELF Program Headers</A>. If a section is assigned to one or more segments, then
|
|
all subsequent allocated sections will be assigned to those segments as
|
|
well, unless they use an explicitly <CODE>:<VAR>phdr</VAR></CODE> modifier. To
|
|
prevent a section from being assigned to a segment when it would
|
|
normally default to one, use <CODE>:NONE</CODE>.
|
|
|
|
<A NAME="IDX314"></A>
|
|
<A NAME="IDX315"></A>
|
|
<A NAME="IDX316"></A>
|
|
<DT><CODE>=<VAR>fill</VAR></CODE>
|
|
<DD>
|
|
Including <CODE>=<VAR>fill</VAR></CODE> in a section definition specifies the
|
|
initial fill value for that section. You may use any expression to
|
|
specify <VAR>fill</VAR>. Any unallocated holes in the current output section
|
|
when written to the output file will be filled with the two least
|
|
significant bytes of the value, repeated as necessary. You can also
|
|
change the fill value with a <CODE>FILL</CODE> statement in the <VAR>contents</VAR>
|
|
of a section definition.
|
|
|
|
</DL>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC22" HREF="ld.html#TOC22">Overlays</A></H3>
|
|
<P>
|
|
<A NAME="IDX317"></A>
|
|
<A NAME="IDX318"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>OVERLAY</CODE> command provides an easy way to describe sections
|
|
which are to be loaded as part of a single memory image but are to be
|
|
run at the same memory address. At run time, some sort of overlay
|
|
manager will copy the overlaid sections in and out of the runtime memory
|
|
address as required, perhaps by simply manipulating addressing bits.
|
|
This approach can be useful, for example, when a certain region of
|
|
memory is faster than another.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>OVERLAY</CODE> command is used within a <CODE>SECTIONS</CODE> command. It
|
|
appears as follows:
|
|
|
|
<PRE>
|
|
OVERLAY <VAR>start</VAR> : [ NOCROSSREFS ] AT ( <VAR>ldaddr</VAR> )
|
|
{
|
|
<VAR>secname1</VAR> { <VAR>contents</VAR> } :<VAR>phdr</VAR> =<VAR>fill</VAR>
|
|
<VAR>secname2</VAR> { <VAR>contents</VAR> } :<VAR>phdr</VAR> =<VAR>fill</VAR>
|
|
...
|
|
} ><VAR>region</VAR> :<VAR>phdr</VAR> =<VAR>fill</VAR>
|
|
</PRE>
|
|
|
|
<P>
|
|
Everything is optional except <CODE>OVERLAY</CODE> (a keyword), and each
|
|
section must have a name (<VAR>secname1</VAR> and <VAR>secname2</VAR> above). The
|
|
section definitions within the <CODE>OVERLAY</CODE> construct are identical to
|
|
those within the general <CODE>SECTIONS</CODE> contruct (see section <A HREF="ld.html#SEC17">Specifying Output Sections</A>),
|
|
except that no addresses and no memory regions may be defined for
|
|
sections within an <CODE>OVERLAY</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
The sections are all defined with the same starting address. The load
|
|
addresses of the sections are arranged such that they are consecutive in
|
|
memory starting at the load address used for the <CODE>OVERLAY</CODE> as a
|
|
whole (as with normal section definitions, the load address is optional,
|
|
and defaults to the start address; the start address is also optional,
|
|
and defaults to <CODE>.</CODE>).
|
|
|
|
</P>
|
|
<P>
|
|
If the <CODE>NOCROSSREFS</CODE> keyword is used, and there any references
|
|
among the sections, the linker will report an error. Since the sections
|
|
all run at the same address, it normally does not make sense for one
|
|
section to refer directly to another. See section <A HREF="ld.html#SEC26">Option Commands</A>.
|
|
|
|
</P>
|
|
<P>
|
|
For each section within the <CODE>OVERLAY</CODE>, the linker automatically
|
|
defines two symbols. The symbol <CODE>__load_start_<VAR>secname</VAR></CODE> is
|
|
defined as the starting load address of the section. The symbol
|
|
<CODE>__load_stop_<VAR>secname</VAR></CODE> is defined as the final load address of
|
|
the section. Any characters within <VAR>secname</VAR> which are not legal
|
|
within C identifiers are removed. C (or assembler) code may use these
|
|
symbols to move the overlaid sections around as necessary.
|
|
|
|
</P>
|
|
<P>
|
|
At the end of the overlay, the value of <CODE>.</CODE> is set to the start
|
|
address of the overlay plus the size of the largest section.
|
|
|
|
</P>
|
|
<P>
|
|
Here is an example. Remember that this would appear inside a
|
|
<CODE>SECTIONS</CODE> construct.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
OVERLAY 0x1000 : AT (0x4000)
|
|
{
|
|
.text0 { o1/*.o(.text) }
|
|
.text1 { o2/*.o(.text) }
|
|
}
|
|
</PRE>
|
|
|
|
<P>
|
|
This will define both <CODE>.text0</CODE> and <CODE>.text1</CODE> to start at
|
|
address 0x1000. <CODE>.text0</CODE> will be loaded at address 0x4000, and
|
|
<CODE>.text1</CODE> will be loaded immediately after <CODE>.text0</CODE>. The
|
|
following symbols will be defined: <CODE>__load_start_text0</CODE>,
|
|
<CODE>__load_stop_text0</CODE>, <CODE>__load_start_text1</CODE>,
|
|
<CODE>__load_stop_text1</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
C code to copy overlay <CODE>.text1</CODE> into the overlay area might look
|
|
like the following.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
extern char __load_start_text1, __load_stop_text1;
|
|
memcpy ((char *) 0x1000, &__load_start_text1,
|
|
&__load_stop_text1 - &__load_start_text1);
|
|
</PRE>
|
|
|
|
<P>
|
|
Note that the <CODE>OVERLAY</CODE> command is just syntactic sugar, since
|
|
everything it does can be done using the more basic commands. The above
|
|
example could have been written identically as follows.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
.text0 0x1000 : AT (0x4000) { o1/*.o(.text) }
|
|
__load_start_text0 = LOADADDR (.text0);
|
|
__load_stop_text0 = LOADADDR (.text0) + SIZEOF (.text0);
|
|
.text1 0x1000 : AT (0x4000 + SIZEOF (.text0)) { o2/*.o(.text) }
|
|
__load_start_text1 = LOADADDR (.text1);
|
|
__load_stop_text1 = LOADADDR (.text1) + SIZEOF (.text1);
|
|
. = 0x1000 + MAX (SIZEOF (.text0), SIZEOF (.text1));
|
|
</PRE>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC23" HREF="ld.html#TOC23">ELF Program Headers</A></H2>
|
|
<P>
|
|
<A NAME="IDX319"></A>
|
|
<A NAME="IDX320"></A>
|
|
<A NAME="IDX321"></A>
|
|
|
|
</P>
|
|
<P>
|
|
The ELF object file format uses <EM>program headers</EM>, which are read by
|
|
the system loader and describe how the program should be loaded into
|
|
memory. These program headers must be set correctly in order to run the
|
|
program on a native ELF system. The linker will create reasonable
|
|
program headers by default. However, in some cases, it is desirable to
|
|
specify the program headers more precisely; the <CODE>PHDRS</CODE> command may
|
|
be used for this purpose. When the <CODE>PHDRS</CODE> command is used, the
|
|
linker will not generate any program headers itself.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>PHDRS</CODE> command is only meaningful when generating an ELF
|
|
output file. It is ignored in other cases. This manual does not
|
|
describe the details of how the system loader interprets program
|
|
headers; for more information, see the ELF ABI. The program headers of
|
|
an ELF file may be displayed using the <SAMP>`-p'</SAMP> option of the
|
|
<CODE>objdump</CODE> command.
|
|
|
|
</P>
|
|
<P>
|
|
This is the syntax of the <CODE>PHDRS</CODE> command. The words <CODE>PHDRS</CODE>,
|
|
<CODE>FILEHDR</CODE>, <CODE>AT</CODE>, and <CODE>FLAGS</CODE> are keywords.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
PHDRS
|
|
{
|
|
<VAR>name</VAR> <VAR>type</VAR> [ FILEHDR ] [ PHDRS ] [ AT ( <VAR>address</VAR> ) ]
|
|
[ FLAGS ( <VAR>flags</VAR> ) ] ;
|
|
}
|
|
</PRE>
|
|
|
|
<P>
|
|
The <VAR>name</VAR> is used only for reference in the <CODE>SECTIONS</CODE> command
|
|
of the linker script. It does not get put into the output file.
|
|
|
|
</P>
|
|
<P>
|
|
Certain program header types describe segments of memory which are
|
|
loaded from the file by the system loader. In the linker script, the
|
|
contents of these segments are specified by directing allocated output
|
|
sections to be placed in the segment. To do this, the command
|
|
describing the output section in the <CODE>SECTIONS</CODE> command should use
|
|
<SAMP>`:<VAR>name</VAR>'</SAMP>, where <VAR>name</VAR> is the name of the program header
|
|
as it appears in the <CODE>PHDRS</CODE> command. See section <A HREF="ld.html#SEC21">Optional Section Attributes</A>.
|
|
|
|
</P>
|
|
<P>
|
|
It is normal for certain sections to appear in more than one segment.
|
|
This merely implies that one segment of memory contains another. This
|
|
is specified by repeating <SAMP>`:<VAR>name</VAR>'</SAMP>, using it once for each
|
|
program header in which the section is to appear.
|
|
|
|
</P>
|
|
<P>
|
|
If a section is placed in one or more segments using <SAMP>`:<VAR>name</VAR>'</SAMP>,
|
|
then all subsequent allocated sections which do not specify
|
|
<SAMP>`:<VAR>name</VAR>'</SAMP> are placed in the same segments. This is for
|
|
convenience, since generally a whole set of contiguous sections will be
|
|
placed in a single segment. To prevent a section from being assigned to
|
|
a segment when it would normally default to one, use <CODE>:NONE</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
The <CODE>FILEHDR</CODE> and <CODE>PHDRS</CODE> keywords which may appear after the
|
|
program header type also indicate contents of the segment of memory.
|
|
The <CODE>FILEHDR</CODE> keyword means that the segment should include the ELF
|
|
file header. The <CODE>PHDRS</CODE> keyword means that the segment should
|
|
include the ELF program headers themselves.
|
|
|
|
</P>
|
|
<P>
|
|
The <VAR>type</VAR> may be one of the following. The numbers indicate the
|
|
value of the keyword.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>PT_NULL</CODE> (0)
|
|
<DD>
|
|
Indicates an unused program header.
|
|
|
|
<DT><CODE>PT_LOAD</CODE> (1)
|
|
<DD>
|
|
Indicates that this program header describes a segment to be loaded from
|
|
the file.
|
|
|
|
<DT><CODE>PT_DYNAMIC</CODE> (2)
|
|
<DD>
|
|
Indicates a segment where dynamic linking information can be found.
|
|
|
|
<DT><CODE>PT_INTERP</CODE> (3)
|
|
<DD>
|
|
Indicates a segment where the name of the program interpreter may be
|
|
found.
|
|
|
|
<DT><CODE>PT_NOTE</CODE> (4)
|
|
<DD>
|
|
Indicates a segment holding note information.
|
|
|
|
<DT><CODE>PT_SHLIB</CODE> (5)
|
|
<DD>
|
|
A reserved program header type, defined but not specified by the ELF
|
|
ABI.
|
|
|
|
<DT><CODE>PT_PHDR</CODE> (6)
|
|
<DD>
|
|
Indicates a segment where the program headers may be found.
|
|
|
|
<DT><VAR>expression</VAR>
|
|
<DD>
|
|
An expression giving the numeric type of the program header. This may
|
|
be used for types not defined above.
|
|
</DL>
|
|
|
|
<P>
|
|
It is possible to specify that a segment should be loaded at a
|
|
particular address in memory. This is done using an <CODE>AT</CODE>
|
|
expression. This is identical to the <CODE>AT</CODE> command used in the
|
|
<CODE>SECTIONS</CODE> command (see section <A HREF="ld.html#SEC21">Optional Section Attributes</A>). Using the <CODE>AT</CODE>
|
|
command for a program header overrides any information in the
|
|
<CODE>SECTIONS</CODE> command.
|
|
|
|
</P>
|
|
<P>
|
|
Normally the segment flags are set based on the sections. The
|
|
<CODE>FLAGS</CODE> keyword may be used to explicitly specify the segment
|
|
flags. The value of <VAR>flags</VAR> must be an integer. It is used to
|
|
set the <CODE>p_flags</CODE> field of the program header.
|
|
|
|
</P>
|
|
<P>
|
|
Here is an example of the use of <CODE>PHDRS</CODE>. This shows a typical set
|
|
of program headers used on a native ELF system.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
PHDRS
|
|
{
|
|
headers PT_PHDR PHDRS ;
|
|
interp PT_INTERP ;
|
|
text PT_LOAD FILEHDR PHDRS ;
|
|
data PT_LOAD ;
|
|
dynamic PT_DYNAMIC ;
|
|
}
|
|
|
|
SECTIONS
|
|
{
|
|
. = SIZEOF_HEADERS;
|
|
.interp : { *(.interp) } :text :interp
|
|
.text : { *(.text) } :text
|
|
.rodata : { *(.rodata) } /* defaults to :text */
|
|
...
|
|
. = . + 0x1000; /* move to a new page in memory */
|
|
.data : { *(.data) } :data
|
|
.dynamic : { *(.dynamic) } :data :dynamic
|
|
...
|
|
}
|
|
</PRE>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC24" HREF="ld.html#TOC24">The Entry Point</A></H2>
|
|
<P>
|
|
<A NAME="IDX322"></A>
|
|
<A NAME="IDX323"></A>
|
|
<A NAME="IDX324"></A>
|
|
The linker command language includes a command specifically for
|
|
defining the first executable instruction in an output file (its
|
|
<EM>entry point</EM>). Its argument is a symbol name:
|
|
|
|
<PRE>
|
|
ENTRY(<VAR>symbol</VAR>)
|
|
</PRE>
|
|
|
|
<P>
|
|
Like symbol assignments, the <CODE>ENTRY</CODE> command may be placed either
|
|
as an independent command in the command file, or among the section
|
|
definitions within the <CODE>SECTIONS</CODE> command--whatever makes the most
|
|
sense for your layout.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX325"></A>
|
|
<CODE>ENTRY</CODE> is only one of several ways of choosing the entry point.
|
|
You may indicate it in any of the following ways (shown in descending
|
|
order of priority: methods higher in the list override methods lower down).
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
the <SAMP>`-e'</SAMP> <VAR>entry</VAR> command-line option;
|
|
<LI>
|
|
|
|
the <CODE>ENTRY(<VAR>symbol</VAR>)</CODE> command in a linker control script;
|
|
<LI>
|
|
|
|
the value of the symbol <CODE>start</CODE>, if present;
|
|
<LI>
|
|
|
|
the address of the first byte of the <CODE>.text</CODE> section, if present;
|
|
<LI>
|
|
|
|
The address <CODE>0</CODE>.
|
|
</UL>
|
|
|
|
<P>
|
|
For example, you can use these rules to generate an entry point with an
|
|
assignment statement: if no symbol <CODE>start</CODE> is defined within your
|
|
input files, you can simply define it, assigning it an appropriate
|
|
value---
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
start = 0x2020;
|
|
</PRE>
|
|
|
|
<P>
|
|
The example shows an absolute address, but you can use any expression.
|
|
For example, if your input object files use some other symbol-name
|
|
convention for the entry point, you can just assign the value of
|
|
whatever symbol contains the start address to <CODE>start</CODE>:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
start = other_symbol ;
|
|
</PRE>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC25" HREF="ld.html#TOC25">Version Script</A></H2>
|
|
<P>
|
|
<A NAME="IDX326"></A>
|
|
<A NAME="IDX327"></A>
|
|
<A NAME="IDX328"></A>
|
|
<A NAME="IDX329"></A>
|
|
The linker command script includes a command specifically for
|
|
specifying a version script, and is only meaningful for ELF platforms
|
|
that support shared libraries. A version script can be
|
|
build directly into the linker script that you are using, or you
|
|
can supply the version script as just another input file to the linker
|
|
at the time that you link. The command script syntax is:
|
|
|
|
<PRE>
|
|
VERSION { version script contents }
|
|
</PRE>
|
|
|
|
<P>
|
|
The version script can also be specified to the linker by means of the
|
|
<SAMP>`--version-script'</SAMP> linker command line option.
|
|
Version scripts are only meaningful when creating shared libraries.
|
|
|
|
</P>
|
|
<P>
|
|
The format of the version script itself is identical to that used by
|
|
Sun's linker in Solaris 2.5. Versioning is done by defining a tree of
|
|
version nodes with the names and interdependencies specified in the
|
|
version script. The version script can specify which symbols are bound
|
|
to which version nodes, and it can reduce a specified set of symbols to
|
|
local scope so that they are not globally visible outside of the shared
|
|
library.
|
|
|
|
</P>
|
|
<P>
|
|
The easiest way to demonstrate the version script language is with a few
|
|
examples.
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
VERS_1.1 {
|
|
global:
|
|
foo1;
|
|
local:
|
|
old*;
|
|
original*;
|
|
new*;
|
|
};
|
|
|
|
VERS_1.2 {
|
|
foo2;
|
|
} VERS_1.1;
|
|
|
|
VERS_2.0 {
|
|
bar1; bar2;
|
|
} VERS_1.2;
|
|
</PRE>
|
|
|
|
<P>
|
|
In this example, three version nodes are defined. <SAMP>`VERS_1.1'</SAMP> is the
|
|
first version node defined, and has no other dependencies. The symbol
|
|
<SAMP>`foo1'</SAMP> is bound to this version node, and a number of symbols
|
|
that have appeared within various object files are reduced in scope to
|
|
local so that they are not visible outside of the shared library.
|
|
|
|
</P>
|
|
<P>
|
|
Next, the node <SAMP>`VERS_1.2'</SAMP> is defined. It depends upon
|
|
<SAMP>`VERS_1.1'</SAMP>. The symbol <SAMP>`foo2'</SAMP> is bound to this version node.
|
|
|
|
</P>
|
|
<P>
|
|
Finally, the node <SAMP>`VERS_2.0'</SAMP> is defined. It depends upon
|
|
<SAMP>`VERS_1.2'</SAMP>. The symbols <SAMP>`bar1'</SAMP> and <SAMP>`bar2'</SAMP> are bound to
|
|
this version node.
|
|
|
|
</P>
|
|
<P>
|
|
Symbols defined in the library which aren't specifically bound to a
|
|
version node are effectively bound to an unspecified base version of the
|
|
library. It is possible to bind all otherwise unspecified symbols to a
|
|
given version node using <SAMP>`global: *'</SAMP> somewhere in the version
|
|
script.
|
|
|
|
</P>
|
|
<P>
|
|
Lexically the names of the version nodes have no specific meaning other
|
|
than what they might suggest to the person reading them. The <SAMP>`2.0'</SAMP>
|
|
version could just as well have appeared in between <SAMP>`1.1'</SAMP> and
|
|
<SAMP>`1.2'</SAMP>. However, this would be a confusing way to write a version
|
|
script.
|
|
|
|
</P>
|
|
<P>
|
|
When you link an application against a shared library that has versioned
|
|
symbols, the application itself knows which version of each symbol it requires,
|
|
and it also knows which version nodes it needs from each shared library it is
|
|
linked against. Thus at runtime, the dynamic loader can make a quick check to
|
|
make sure that the libraries you have linked against do in fact supply all
|
|
of the version nodes that the application will need to resolve all of the
|
|
dynamic symbols. In this way it is possible for the dynamic linker to know
|
|
with certainty that all external symbols that it needs will be resolvable
|
|
without having to search for each symbol reference.
|
|
|
|
</P>
|
|
<P>
|
|
The symbol versioning is in effect a much more sophisticated way of
|
|
doing minor version checking that SunOS does. The fundamental problem
|
|
that is being addressed here is that typically references to external
|
|
functions are bound on an as-needed basis, and are not all bound when
|
|
the application starts up. If a shared library is out of date, a
|
|
required interface may be missing; when the application tries to use
|
|
that interface, it may suddenly and unexpectedly fail. With symbol
|
|
versioning, the user will get a warning when they start their program if
|
|
the libraries being used with the application are too old.
|
|
|
|
</P>
|
|
<P>
|
|
There are several GNU extensions to Sun's versioning approach. The
|
|
first of these is the ability to bind a symbol to a version node in the
|
|
source file where the symbol is defined instead of in the versioning
|
|
script. This was done mainly to reduce the burden on the library
|
|
maintainer. This can be done by putting something like:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
__asm__(".symver original_foo,foo@VERS_1.1");
|
|
</PRE>
|
|
|
|
<P>
|
|
in the C source file. This renamed the function <SAMP>`original_foo'</SAMP> to
|
|
be an alias for <SAMP>`foo'</SAMP> bound to the version node <SAMP>`VERS_1.1'</SAMP>.
|
|
The <SAMP>`local:'</SAMP> directive can be used to prevent the symbol
|
|
<SAMP>`original_foo'</SAMP> from being exported.
|
|
|
|
</P>
|
|
<P>
|
|
The second GNU extension is to allow multiple versions of the same function
|
|
to appear in a given shared library. In this way an incompatible change to
|
|
an interface can take place without increasing the major version number of
|
|
the shared library, while still allowing applications linked against the old
|
|
interface to continue to function.
|
|
|
|
</P>
|
|
<P>
|
|
This can only be accomplished by using multiple <SAMP>`.symver'</SAMP>
|
|
directives in the assembler. An example of this would be:
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
__asm__(".symver original_foo,foo@");
|
|
__asm__(".symver old_foo,foo@VERS_1.1");
|
|
__asm__(".symver old_foo1,foo@VERS_1.2");
|
|
__asm__(".symver new_foo,foo@@VERS_2.0");
|
|
</PRE>
|
|
|
|
<P>
|
|
In this example, <SAMP>`foo@'</SAMP> represents the symbol <SAMP>`foo'</SAMP> bound to the
|
|
unspecified base version of the symbol. The source file that contains this
|
|
example would define 4 C functions: <SAMP>`original_foo'</SAMP>, <SAMP>`old_foo'</SAMP>,
|
|
<SAMP>`old_foo1'</SAMP>, and <SAMP>`new_foo'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
When you have multiple definitions of a given symbol, there needs to be
|
|
some way to specify a default version to which external references to
|
|
this symbol will be bound. This can be accomplished with the
|
|
<SAMP>`foo@@VERS_2.0'</SAMP> type of <SAMP>`.symver'</SAMP> directive. Only one version of
|
|
a symbol can be declared 'default' in this manner - otherwise you would
|
|
effectively have multiple definitions of the same symbol.
|
|
|
|
</P>
|
|
<P>
|
|
If you wish to bind a reference to a specific version of the symbol
|
|
within the shared library, you can use the aliases of convenience
|
|
(i.e. <SAMP>`old_foo'</SAMP>), or you can use the <SAMP>`.symver'</SAMP> directive to
|
|
specifically bind to an external version of the function in question.
|
|
|
|
</P>
|
|
|
|
|
|
<H2><A NAME="SEC26" HREF="ld.html#TOC26">Option Commands</A></H2>
|
|
<P>
|
|
The command language includes a number of other commands that you can
|
|
use for specialized purposes. They are similar in purpose to
|
|
command-line options.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>CONSTRUCTORS</CODE>
|
|
<DD>
|
|
<A NAME="IDX330"></A>
|
|
<A NAME="IDX331"></A>
|
|
<A NAME="IDX332"></A>
|
|
|
|
When linking using the <CODE>a.out</CODE> object file format, the linker uses
|
|
an unusual set construct to support C++ global constructors and
|
|
destructors. When linking object file formats which do not support
|
|
arbitrary sections, such as <CODE>ECOFF</CODE> and <CODE>XCOFF</CODE>, the linker
|
|
will automatically recognize C++ global constructors and destructors by
|
|
name. For these object file formats, the <CODE>CONSTRUCTORS</CODE> command
|
|
tells the linker where this information should be placed. The
|
|
<CODE>CONSTRUCTORS</CODE> command is ignored for other object file formats.
|
|
|
|
The symbol <CODE>__CTOR_LIST__</CODE> marks the start of the global
|
|
constructors, and the symbol <CODE>__DTOR_LIST</CODE> marks the end. The
|
|
first word in the list is the number of entries, followed by the address
|
|
of each constructor or destructor, followed by a zero word. The
|
|
compiler must arrange to actually run the code. For these object file
|
|
formats GNU C++ calls constructors from a subroutine <CODE>__main</CODE>;
|
|
a call to <CODE>__main</CODE> is automatically inserted into the startup code
|
|
for <CODE>main</CODE>. GNU C++ runs destructors either by using
|
|
<CODE>atexit</CODE>, or directly from the function <CODE>exit</CODE>.
|
|
|
|
For object file formats such as <CODE>COFF</CODE> or <CODE>ELF</CODE> which support
|
|
multiple sections, GNU C++ will normally arrange to put the
|
|
addresses of global constructors and destructors into the <CODE>.ctors</CODE>
|
|
and <CODE>.dtors</CODE> sections. Placing the following sequence into your
|
|
linker script will build the sort of table which the GNU C++
|
|
runtime code expects to see.
|
|
|
|
|
|
<PRE>
|
|
__CTOR_LIST__ = .;
|
|
LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
|
|
*(.ctors)
|
|
LONG(0)
|
|
__CTOR_END__ = .;
|
|
__DTOR_LIST__ = .;
|
|
LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
|
|
*(.dtors)
|
|
LONG(0)
|
|
__DTOR_END__ = .;
|
|
</PRE>
|
|
|
|
Normally the compiler and linker will handle these issues automatically,
|
|
and you will not need to concern yourself with them. However, you may
|
|
need to consider this if you are using C++ and writing your own linker
|
|
scripts.
|
|
|
|
<A NAME="IDX333"></A>
|
|
<A NAME="IDX334"></A>
|
|
<DT><CODE>FLOAT</CODE>
|
|
<DD>
|
|
<DT><CODE>NOFLOAT</CODE>
|
|
<DD>
|
|
These keywords were used in some older linkers to request a particular
|
|
math subroutine library. <CODE>ld</CODE> doesn't use the keywords, assuming
|
|
instead that any necessary subroutines are in libraries specified using
|
|
the general mechanisms for linking to archives; but to permit the use of
|
|
scripts that were written for the older linkers, the keywords
|
|
<CODE>FLOAT</CODE> and <CODE>NOFLOAT</CODE> are accepted and ignored.
|
|
|
|
<A NAME="IDX335"></A>
|
|
<A NAME="IDX336"></A>
|
|
<DT><CODE>FORCE_COMMON_ALLOCATION</CODE>
|
|
<DD>
|
|
This command has the same effect as the <SAMP>`-d'</SAMP> command-line option:
|
|
to make <CODE>ld</CODE> assign space to common symbols even if a relocatable
|
|
output file is specified (<SAMP>`-r'</SAMP>).
|
|
|
|
<A NAME="IDX337"></A>
|
|
<A NAME="IDX338"></A>
|
|
<DT><CODE>INCLUDE <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
Include the linker script <VAR>filename</VAR> at this point. The file will
|
|
be searched for in the current directory, and in any directory specified
|
|
with the <CODE>-L</CODE> option. You can nest calls to <CODE>INCLUDE</CODE> up to
|
|
10 levels deep.
|
|
|
|
<A NAME="IDX339"></A>
|
|
<A NAME="IDX340"></A>
|
|
<DT><CODE>INPUT ( <VAR>file</VAR>, <VAR>file</VAR>, ... )</CODE>
|
|
<DD>
|
|
<DT><CODE>INPUT ( <VAR>file</VAR> <VAR>file</VAR> ... )</CODE>
|
|
<DD>
|
|
Use this command to include binary input files in the link, without
|
|
including them in a particular section definition.
|
|
Specify the full name for each <VAR>file</VAR>, including <SAMP>`.a'</SAMP> if
|
|
required.
|
|
|
|
<CODE>ld</CODE> searches for each <VAR>file</VAR> through the archive-library
|
|
search path, just as for files you specify on the command line.
|
|
See the description of <SAMP>`-L'</SAMP> in section <A HREF="ld.html#SEC3">Command Line Options</A>.
|
|
|
|
If you use <SAMP>`-l<VAR>file</VAR>'</SAMP>, <CODE>ld</CODE> will transform the name to
|
|
<CODE>lib<VAR>file</VAR>.a</CODE> as with the command line argument <SAMP>`-l'</SAMP>.
|
|
|
|
<A NAME="IDX341"></A>
|
|
<A NAME="IDX342"></A>
|
|
<DT><CODE>GROUP ( <VAR>file</VAR>, <VAR>file</VAR>, ... )</CODE>
|
|
<DD>
|
|
<DT><CODE>GROUP ( <VAR>file</VAR> <VAR>file</VAR> ... )</CODE>
|
|
<DD>
|
|
This command is like <CODE>INPUT</CODE>, except that the named files should
|
|
all be archives, and they are searched repeatedly until no new undefined
|
|
references are created. See the description of <SAMP>`-('</SAMP> in
|
|
section <A HREF="ld.html#SEC3">Command Line Options</A>.
|
|
|
|
<A NAME="IDX343"></A>
|
|
<A NAME="IDX344"></A>
|
|
<DT><CODE>OUTPUT ( <VAR>filename</VAR> )</CODE>
|
|
<DD>
|
|
Use this command to name the link output file <VAR>filename</VAR>. The
|
|
effect of <CODE>OUTPUT(<VAR>filename</VAR>)</CODE> is identical to the effect of
|
|
<SAMP>`-o <VAR>filename</VAR>'</SAMP>, which overrides it. You can use this
|
|
command to supply a default output-file name other than <CODE>a.out</CODE>.
|
|
|
|
<A NAME="IDX345"></A>
|
|
<A NAME="IDX346"></A>
|
|
<DT><CODE>OUTPUT_ARCH ( <VAR>bfdname</VAR> )</CODE>
|
|
<DD>
|
|
Specify a particular output machine architecture, with one of the names
|
|
used by the BFD back-end routines (see section <A HREF="ld.html#SEC30">BFD</A>). This command is often
|
|
unnecessary; the architecture is most often set implicitly by either the
|
|
system BFD configuration or as a side effect of the <CODE>OUTPUT_FORMAT</CODE>
|
|
command.
|
|
|
|
<A NAME="IDX347"></A>
|
|
<A NAME="IDX348"></A>
|
|
<DT><CODE>OUTPUT_FORMAT ( <VAR>bfdname</VAR> )</CODE>
|
|
<DD>
|
|
When <CODE>ld</CODE> is configured to support multiple object code formats,
|
|
you can use this command to specify a particular output format.
|
|
<VAR>bfdname</VAR> is one of the names used by the BFD back-end routines
|
|
(see section <A HREF="ld.html#SEC30">BFD</A>). The effect is identical to the effect of the
|
|
<SAMP>`--oformat'</SAMP> command-line option. This selection affects only the
|
|
output file; the related command <CODE>TARGET</CODE> affects primarily input
|
|
files.
|
|
|
|
<A NAME="IDX349"></A>
|
|
<A NAME="IDX350"></A>
|
|
<A NAME="IDX351"></A>
|
|
<DT><CODE>SEARCH_DIR ( <VAR>path</VAR> )</CODE>
|
|
<DD>
|
|
Add <VAR>path</VAR> to the list of paths where <CODE>ld</CODE> looks for
|
|
archive libraries. <CODE>SEARCH_DIR(<VAR>path</VAR>)</CODE> has the same
|
|
effect as <SAMP>`-L<VAR>path</VAR>'</SAMP> on the command line.
|
|
|
|
<A NAME="IDX352"></A>
|
|
<A NAME="IDX353"></A>
|
|
<DT><CODE>STARTUP ( <VAR>filename</VAR> )</CODE>
|
|
<DD>
|
|
Ensure that <VAR>filename</VAR> is the first input file used in the link
|
|
process.
|
|
|
|
<A NAME="IDX354"></A>
|
|
<A NAME="IDX355"></A>
|
|
<DT><CODE>TARGET ( <VAR>format</VAR> )</CODE>
|
|
<DD>
|
|
When <CODE>ld</CODE> is configured to support multiple object code formats,
|
|
you can use this command to change the input-file object code format
|
|
(like the command-line option <SAMP>`-b'</SAMP> or its synonym <SAMP>`--format'</SAMP>).
|
|
The argument <VAR>format</VAR> is one of the strings used by BFD to name
|
|
binary formats. If <CODE>TARGET</CODE> is specified but <CODE>OUTPUT_FORMAT</CODE>
|
|
is not, the last <CODE>TARGET</CODE> argument is also used as the default
|
|
format for the <CODE>ld</CODE> output file. See section <A HREF="ld.html#SEC30">BFD</A>.
|
|
|
|
<A NAME="IDX356"></A>
|
|
If you don't use the <CODE>TARGET</CODE> command, <CODE>ld</CODE> uses the value of
|
|
the environment variable <CODE>GNUTARGET</CODE>, if available, to select the
|
|
output file format. If that variable is also absent, <CODE>ld</CODE> uses
|
|
the default format configured for your machine in the BFD libraries.
|
|
|
|
<A NAME="IDX357"></A>
|
|
<A NAME="IDX358"></A>
|
|
<DT><CODE>NOCROSSREFS ( <VAR>section</VAR> <VAR>section</VAR> ... )</CODE>
|
|
<DD>
|
|
This command may be used to tell <CODE>ld</CODE> to issue an error about any
|
|
references among certain sections.
|
|
|
|
In certain types of programs, particularly on embedded systems, when one
|
|
section is loaded into memory, another section will not be. Any direct
|
|
references between the two sections would be errors. For example, it
|
|
would be an error if code in one section called a function defined in
|
|
the other section.
|
|
|
|
The <CODE>NOCROSSREFS</CODE> command takes a list of section names. If
|
|
<CODE>ld</CODE> detects any cross references between the sections, it reports
|
|
an error and returns a non-zero exit status. The <CODE>NOCROSSREFS</CODE>
|
|
command uses output section names, defined in the <CODE>SECTIONS</CODE>
|
|
command. It does not use the names of input sections.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC27" HREF="ld.html#TOC27">Machine Dependent Features</A></H1>
|
|
|
|
<P>
|
|
<A NAME="IDX359"></A>
|
|
<CODE>ld</CODE> has additional features on some platforms; the following
|
|
sections describe them. Machines where <CODE>ld</CODE> has no additional
|
|
functionality are not listed.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC28" HREF="ld.html#TOC28"><CODE>ld</CODE> and the H8/300</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX360"></A>
|
|
For the H8/300, <CODE>ld</CODE> can perform these global optimizations when
|
|
you specify the <SAMP>`--relax'</SAMP> command-line option.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><EM>relaxing address modes</EM>
|
|
<DD>
|
|
<A NAME="IDX361"></A>
|
|
|
|
<CODE>ld</CODE> finds all <CODE>jsr</CODE> and <CODE>jmp</CODE> instructions whose
|
|
targets are within eight bits, and turns them into eight-bit
|
|
program-counter relative <CODE>bsr</CODE> and <CODE>bra</CODE> instructions,
|
|
respectively.
|
|
|
|
<A NAME="IDX362"></A>
|
|
<DT><EM>synthesizing instructions</EM>
|
|
<DD>
|
|
<CODE>ld</CODE> finds all <CODE>mov.b</CODE> instructions which use the
|
|
sixteen-bit absolute address form, but refer to the top
|
|
page of memory, and changes them to use the eight-bit address form.
|
|
(That is: the linker turns <SAMP>`mov.b <CODE>@</CODE><VAR>aa</VAR>:16'</SAMP> into
|
|
<SAMP>`mov.b <CODE>@</CODE><VAR>aa</VAR>:8'</SAMP> whenever the address <VAR>aa</VAR> is in the
|
|
top page of memory).
|
|
</DL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC29" HREF="ld.html#TOC29"><CODE>ld</CODE> and the Intel 960 family</A></H2>
|
|
|
|
<P>
|
|
<A NAME="IDX363"></A>
|
|
|
|
</P>
|
|
<P>
|
|
You can use the <SAMP>`-A<VAR>architecture</VAR>'</SAMP> command line option to
|
|
specify one of the two-letter names identifying members of the 960
|
|
family; the option specifies the desired output target, and warns of any
|
|
incompatible instructions in the input files. It also modifies the
|
|
linker's search strategy for archive libraries, to support the use of
|
|
libraries specific to each particular architecture, by including in the
|
|
search loop names suffixed with the string identifying the architecture.
|
|
|
|
</P>
|
|
<P>
|
|
For example, if your <CODE>ld</CODE> command line included <SAMP>`-ACA'</SAMP> as
|
|
well as <SAMP>`-ltry'</SAMP>, the linker would look (in its built-in search
|
|
paths, and in any paths you specify with <SAMP>`-L'</SAMP>) for a library with
|
|
the names
|
|
|
|
</P>
|
|
|
|
<PRE>
|
|
try
|
|
libtry.a
|
|
tryca
|
|
libtryca.a
|
|
</PRE>
|
|
|
|
<P>
|
|
The first two possibilities would be considered in any event; the last
|
|
two are due to the use of <SAMP>`-ACA'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
You can meaningfully use <SAMP>`-A'</SAMP> more than once on a command line, since
|
|
the 960 architecture family allows combination of target architectures; each
|
|
use will add another pair of name variants to search for when <SAMP>`-l'</SAMP>
|
|
specifies a library.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX364"></A>
|
|
<A NAME="IDX365"></A>
|
|
<CODE>ld</CODE> supports the <SAMP>`--relax'</SAMP> option for the i960 family. If
|
|
you specify <SAMP>`--relax'</SAMP>, <CODE>ld</CODE> finds all <CODE>balx</CODE> and
|
|
<CODE>calx</CODE> instructions whose targets are within 24 bits, and turns
|
|
them into 24-bit program-counter relative <CODE>bal</CODE> and <CODE>cal</CODE>
|
|
instructions, respectively. <CODE>ld</CODE> also turns <CODE>cal</CODE>
|
|
instructions into <CODE>bal</CODE> instructions when it determines that the
|
|
target subroutine is a leaf routine (that is, the target subroutine does
|
|
not itself call any subroutines).
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC30" HREF="ld.html#TOC30">BFD</A></H1>
|
|
|
|
<P>
|
|
<A NAME="IDX366"></A>
|
|
<A NAME="IDX367"></A>
|
|
<A NAME="IDX368"></A>
|
|
<A NAME="IDX369"></A>
|
|
The linker accesses object and archive files using the BFD libraries.
|
|
These libraries allow the linker to use the same routines to operate on
|
|
object files whatever the object file format. A different object file
|
|
format can be supported simply by creating a new BFD back end and adding
|
|
it to the library. To conserve runtime memory, however, the linker and
|
|
associated tools are usually configured to support only a subset of the
|
|
object file formats available. You can use <CODE>objdump -i</CODE>
|
|
(see section `objdump' in <CITE>The GNU Binary Utilities</CITE>) to
|
|
list all the formats available for your configuration.
|
|
|
|
</P>
|
|
<P>
|
|
<A NAME="IDX370"></A>
|
|
<A NAME="IDX371"></A>
|
|
As with most implementations, BFD is a compromise between
|
|
several conflicting requirements. The major factor influencing
|
|
BFD design was efficiency: any time used converting between
|
|
formats is time which would not have been spent had BFD not
|
|
been involved. This is partly offset by abstraction payback; since
|
|
BFD simplifies applications and back ends, more time and care
|
|
may be spent optimizing algorithms for a greater speed.
|
|
|
|
</P>
|
|
<P>
|
|
One minor artifact of the BFD solution which you should bear in
|
|
mind is the potential for information loss. There are two places where
|
|
useful information can be lost using the BFD mechanism: during
|
|
conversion and during output. See section <A HREF="ld.html#SEC32">Information Loss</A>.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC31" HREF="ld.html#TOC31">How it works: an outline of BFD</A></H2>
|
|
<P>
|
|
<A NAME="IDX372"></A>
|
|
When an object file is opened, BFD subroutines automatically determine
|
|
the format of the input object file. They then build a descriptor in
|
|
memory with pointers to routines that will be used to access elements of
|
|
the object file's data structures.
|
|
|
|
</P>
|
|
<P>
|
|
As different information from the the object files is required,
|
|
BFD reads from different sections of the file and processes them.
|
|
For example, a very common operation for the linker is processing symbol
|
|
tables. Each BFD back end provides a routine for converting
|
|
between the object file's representation of symbols and an internal
|
|
canonical format. When the linker asks for the symbol table of an object
|
|
file, it calls through a memory pointer to the routine from the
|
|
relevant BFD back end which reads and converts the table into a canonical
|
|
form. The linker then operates upon the canonical form. When the link is
|
|
finished and the linker writes the output file's symbol table,
|
|
another BFD back end routine is called to take the newly
|
|
created symbol table and convert it into the chosen output format.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H3><A NAME="SEC32" HREF="ld.html#TOC32">Information Loss</A></H3>
|
|
|
|
<P>
|
|
<EM>Information can be lost during output.</EM> The output formats
|
|
supported by BFD do not provide identical facilities, and
|
|
information which can be described in one form has nowhere to go in
|
|
another format. One example of this is alignment information in
|
|
<CODE>b.out</CODE>. There is nowhere in an <CODE>a.out</CODE> format file to store
|
|
alignment information on the contained data, so when a file is linked
|
|
from <CODE>b.out</CODE> and an <CODE>a.out</CODE> image is produced, alignment
|
|
information will not propagate to the output file. (The linker will
|
|
still use the alignment information internally, so the link is performed
|
|
correctly).
|
|
|
|
</P>
|
|
<P>
|
|
Another example is COFF section names. COFF files may contain an
|
|
unlimited number of sections, each one with a textual section name. If
|
|
the target of the link is a format which does not have many sections (e.g.,
|
|
<CODE>a.out</CODE>) or has sections without names (e.g., the Oasys format), the
|
|
link cannot be done simply. You can circumvent this problem by
|
|
describing the desired input-to-output section mapping with the linker command
|
|
language.
|
|
|
|
</P>
|
|
<P>
|
|
<EM>Information can be lost during canonicalization.</EM> The BFD
|
|
internal canonical form of the external formats is not exhaustive; there
|
|
are structures in input formats for which there is no direct
|
|
representation internally. This means that the BFD back ends
|
|
cannot maintain all possible data richness through the transformation
|
|
between external to internal and back to external formats.
|
|
|
|
</P>
|
|
<P>
|
|
This limitation is only a problem when an application reads one
|
|
format and writes another. Each BFD back end is responsible for
|
|
maintaining as much data as possible, and the internal BFD
|
|
canonical form has structures which are opaque to the BFD core,
|
|
and exported only to the back ends. When a file is read in one format,
|
|
the canonical form is generated for BFD and the application. At the
|
|
same time, the back end saves away any information which may otherwise
|
|
be lost. If the data is then written back in the same format, the back
|
|
end routine will be able to use the canonical form provided by the
|
|
BFD core as well as the information it prepared earlier. Since
|
|
there is a great deal of commonality between back ends,
|
|
there is no information lost when
|
|
linking or copying big endian COFF to little endian COFF, or <CODE>a.out</CODE> to
|
|
<CODE>b.out</CODE>. When a mixture of formats is linked, the information is
|
|
only lost from the files whose format differs from the destination.
|
|
|
|
</P>
|
|
|
|
|
|
<H3><A NAME="SEC33" HREF="ld.html#TOC33">The BFD canonical object-file format</A></H3>
|
|
|
|
<P>
|
|
The greatest potential for loss of information occurs when there is the least
|
|
overlap between the information provided by the source format, that
|
|
stored by the canonical format, and that needed by the
|
|
destination format. A brief description of the canonical form may help
|
|
you understand which kinds of data you can count on preserving across
|
|
conversions.
|
|
<A NAME="IDX373"></A>
|
|
<A NAME="IDX374"></A>
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><EM>files</EM>
|
|
<DD>
|
|
Information stored on a per-file basis includes target machine
|
|
architecture, particular implementation format type, a demand pageable
|
|
bit, and a write protected bit. Information like Unix magic numbers is
|
|
not stored here--only the magic numbers' meaning, so a <CODE>ZMAGIC</CODE>
|
|
file would have both the demand pageable bit and the write protected
|
|
text bit set. The byte order of the target is stored on a per-file
|
|
basis, so that big- and little-endian object files may be used with one
|
|
another.
|
|
|
|
<DT><EM>sections</EM>
|
|
<DD>
|
|
Each section in the input file contains the name of the section, the
|
|
section's original address in the object file, size and alignment
|
|
information, various flags, and pointers into other BFD data
|
|
structures.
|
|
|
|
<DT><EM>symbols</EM>
|
|
<DD>
|
|
Each symbol contains a pointer to the information for the object file
|
|
which originally defined it, its name, its value, and various flag
|
|
bits. When a BFD back end reads in a symbol table, it relocates all
|
|
symbols to make them relative to the base of the section where they were
|
|
defined. Doing this ensures that each symbol points to its containing
|
|
section. Each symbol also has a varying amount of hidden private data
|
|
for the BFD back end. Since the symbol points to the original file, the
|
|
private data format for that symbol is accessible. <CODE>ld</CODE> can
|
|
operate on a collection of symbols of wildly different formats without
|
|
problems.
|
|
|
|
Normal global and simple local symbols are maintained on output, so an
|
|
output file (no matter its format) will retain symbols pointing to
|
|
functions and to global, static, and common variables. Some symbol
|
|
information is not worth retaining; in <CODE>a.out</CODE>, type information is
|
|
stored in the symbol table as long symbol names. This information would
|
|
be useless to most COFF debuggers; the linker has command line switches
|
|
to allow users to throw it away.
|
|
|
|
There is one word of type information within the symbol, so if the
|
|
format supports symbol type information within symbols (for example, COFF,
|
|
IEEE, Oasys) and the type is simple enough to fit within one word
|
|
(nearly everything but aggregates), the information will be preserved.
|
|
|
|
<DT><EM>relocation level</EM>
|
|
<DD>
|
|
Each canonical BFD relocation record contains a pointer to the symbol to
|
|
relocate to, the offset of the data to relocate, the section the data
|
|
is in, and a pointer to a relocation type descriptor. Relocation is
|
|
performed by passing messages through the relocation type
|
|
descriptor and the symbol pointer. Therefore, relocations can be performed
|
|
on output data using a relocation method that is only available in one of the
|
|
input formats. For instance, Oasys provides a byte relocation format.
|
|
A relocation record requesting this relocation type would point
|
|
indirectly to a routine to perform this, so the relocation may be
|
|
performed on a byte being written to a 68k COFF file, even though 68k COFF
|
|
has no such relocation type.
|
|
|
|
<DT><EM>line numbers</EM>
|
|
<DD>
|
|
Object formats can contain, for debugging purposes, some form of mapping
|
|
between symbols, source line numbers, and addresses in the output file.
|
|
These addresses have to be relocated along with the symbol information.
|
|
Each symbol with an associated list of line number records points to the
|
|
first record of the list. The head of a line number list consists of a
|
|
pointer to the symbol, which allows finding out the address of the
|
|
function whose line number is being described. The rest of the list is
|
|
made up of pairs: offsets into the section and line numbers. Any format
|
|
which can simply derive this information can pass it successfully
|
|
between formats (COFF, IEEE and Oasys).
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC34" HREF="ld.html#TOC34">Reporting Bugs</A></H1>
|
|
<P>
|
|
<A NAME="IDX375"></A>
|
|
<A NAME="IDX376"></A>
|
|
|
|
</P>
|
|
<P>
|
|
Your bug reports play an essential role in making <CODE>ld</CODE> reliable.
|
|
|
|
</P>
|
|
<P>
|
|
Reporting a bug may help you by bringing a solution to your problem, or
|
|
it may not. But in any case the principal function of a bug report is
|
|
to help the entire community by making the next version of <CODE>ld</CODE>
|
|
work better. Bug reports are your contribution to the maintenance of
|
|
<CODE>ld</CODE>.
|
|
|
|
</P>
|
|
<P>
|
|
In order for a bug report to serve its purpose, you must include the
|
|
information that enables us to fix the bug.
|
|
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC35" HREF="ld.html#TOC35">Have you found a bug?</A></H2>
|
|
<P>
|
|
<A NAME="IDX377"></A>
|
|
|
|
</P>
|
|
<P>
|
|
If you are not sure whether you have found a bug, here are some guidelines:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
<A NAME="IDX378"></A>
|
|
<A NAME="IDX379"></A>
|
|
<A NAME="IDX380"></A>
|
|
|
|
If the linker gets a fatal signal, for any input whatever, that is a
|
|
<CODE>ld</CODE> bug. Reliable linkers never crash.
|
|
|
|
<A NAME="IDX381"></A>
|
|
<LI>
|
|
|
|
If <CODE>ld</CODE> produces an error message for valid input, that is a bug.
|
|
|
|
<A NAME="IDX382"></A>
|
|
<LI>
|
|
|
|
If <CODE>ld</CODE> does not produce an error message for invalid input, that
|
|
may be a bug. In the general case, the linker can not verify that
|
|
object files are correct.
|
|
|
|
<LI>
|
|
|
|
If you are an experienced user of linkers, your suggestions for
|
|
improvement of <CODE>ld</CODE> are welcome in any case.
|
|
</UL>
|
|
|
|
|
|
|
|
<H2><A NAME="SEC36" HREF="ld.html#TOC36">How to report bugs</A></H2>
|
|
<P>
|
|
<A NAME="IDX383"></A>
|
|
<A NAME="IDX384"></A>
|
|
|
|
</P>
|
|
<P>
|
|
A number of companies and individuals offer support for GNU
|
|
products. If you obtained <CODE>ld</CODE> from a support organization, we
|
|
recommend you contact that organization first.
|
|
|
|
</P>
|
|
<P>
|
|
You can find contact information for many support companies and
|
|
individuals in the file <TT>`etc/SERVICE'</TT> in the GNU Emacs
|
|
distribution.
|
|
|
|
</P>
|
|
<P>
|
|
In any event, we also recommend that you send bug reports for <CODE>ld</CODE>
|
|
to <SAMP>`bug-gnu-utils@gnu.org'</SAMP>.
|
|
|
|
</P>
|
|
<P>
|
|
The fundamental principle of reporting bugs usefully is this:
|
|
<STRONG>report all the facts</STRONG>. If you are not sure whether to state a
|
|
fact or leave it out, state it!
|
|
|
|
</P>
|
|
<P>
|
|
Often people omit facts because they think they know what causes the
|
|
problem and assume that some details do not matter. Thus, you might
|
|
assume that the name of a symbol you use in an example does not matter.
|
|
Well, probably it does not, but one cannot be sure. Perhaps the bug is
|
|
a stray memory reference which happens to fetch from the location where
|
|
that name is stored in memory; perhaps, if the name were different, the
|
|
contents of that location would fool the linker into doing the right
|
|
thing despite the bug. Play it safe and give a specific, complete
|
|
example. That is the easiest thing for you to do, and the most helpful.
|
|
|
|
</P>
|
|
<P>
|
|
Keep in mind that the purpose of a bug report is to enable us to fix the bug if
|
|
it is new to us. Therefore, always write your bug reports on the assumption
|
|
that the bug has not been reported previously.
|
|
|
|
</P>
|
|
<P>
|
|
Sometimes people give a few sketchy facts and ask, "Does this ring a
|
|
bell?" Those bug reports are useless, and we urge everyone to
|
|
<EM>refuse to respond to them</EM> except to chide the sender to report
|
|
bugs properly.
|
|
|
|
</P>
|
|
<P>
|
|
To enable us to fix the bug, you should include all these things:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
The version of <CODE>ld</CODE>. <CODE>ld</CODE> announces it if you start it with
|
|
the <SAMP>`--version'</SAMP> argument.
|
|
|
|
Without this, we will not know whether there is any point in looking for
|
|
the bug in the current version of <CODE>ld</CODE>.
|
|
|
|
<LI>
|
|
|
|
Any patches you may have applied to the <CODE>ld</CODE> source, including any
|
|
patches made to the <CODE>BFD</CODE> library.
|
|
|
|
<LI>
|
|
|
|
The type of machine you are using, and the operating system name and
|
|
version number.
|
|
|
|
<LI>
|
|
|
|
What compiler (and its version) was used to compile <CODE>ld</CODE>---e.g.
|
|
"<CODE>gcc-2.7</CODE>".
|
|
|
|
<LI>
|
|
|
|
The command arguments you gave the linker to link your example and
|
|
observe the bug. To guarantee you will not omit something important,
|
|
list them all. A copy of the Makefile (or the output from make) is
|
|
sufficient.
|
|
|
|
If we were to try to guess the arguments, we would probably guess wrong
|
|
and then we might not encounter the bug.
|
|
|
|
<LI>
|
|
|
|
A complete input file, or set of input files, that will reproduce the
|
|
bug. It is generally most helpful to send the actual object files,
|
|
uuencoded if necessary to get them through the mail system. Making them
|
|
available for anonymous FTP is not as good, but may be the only
|
|
reasonable choice for large object files.
|
|
|
|
If the source files were assembled using <CODE>gas</CODE> or compiled using
|
|
<CODE>gcc</CODE>, then it may be OK to send the source files rather than the
|
|
object files. In this case, be sure to say exactly what version of
|
|
<CODE>gas</CODE> or <CODE>gcc</CODE> was used to produce the object files. Also say
|
|
how <CODE>gas</CODE> or <CODE>gcc</CODE> were configured.
|
|
|
|
<LI>
|
|
|
|
A description of what behavior you observe that you believe is
|
|
incorrect. For example, "It gets a fatal signal."
|
|
|
|
Of course, if the bug is that <CODE>ld</CODE> gets a fatal signal, then we
|
|
will certainly notice it. But if the bug is incorrect output, we might
|
|
not notice unless it is glaringly wrong. You might as well not give us
|
|
a chance to make a mistake.
|
|
|
|
Even if the problem you experience is a fatal signal, you should still
|
|
say so explicitly. Suppose something strange is going on, such as, your
|
|
copy of <CODE>ld</CODE> is out of synch, or you have encountered a bug in the
|
|
C library on your system. (This has happened!) Your copy might crash
|
|
and ours would not. If you told us to expect a crash, then when ours
|
|
fails to crash, we would know that the bug was not happening for us. If
|
|
you had not told us to expect a crash, then we would not be able to draw
|
|
any conclusion from our observations.
|
|
|
|
<LI>
|
|
|
|
If you wish to suggest changes to the <CODE>ld</CODE> source, send us context
|
|
diffs, as generated by <CODE>diff</CODE> with the <SAMP>`-u'</SAMP>, <SAMP>`-c'</SAMP>, or
|
|
<SAMP>`-p'</SAMP> option. Always send diffs from the old file to the new file.
|
|
If you even discuss something in the <CODE>ld</CODE> source, refer to it by
|
|
context, not by line number.
|
|
|
|
The line numbers in our development sources will not match those in your
|
|
sources. Your line numbers would convey no useful information to us.
|
|
</UL>
|
|
|
|
<P>
|
|
Here are some things that are not necessary:
|
|
|
|
</P>
|
|
|
|
<UL>
|
|
<LI>
|
|
|
|
A description of the envelope of the bug.
|
|
|
|
Often people who encounter a bug spend a lot of time investigating
|
|
which changes to the input file will make the bug go away and which
|
|
changes will not affect it.
|
|
|
|
This is often time consuming and not very useful, because the way we
|
|
will find the bug is by running a single example under the debugger
|
|
with breakpoints, not by pure deduction from a series of examples.
|
|
We recommend that you save your time for something else.
|
|
|
|
Of course, if you can find a simpler example to report <EM>instead</EM>
|
|
of the original one, that is a convenience for us. Errors in the
|
|
output will be easier to spot, running under the debugger will take
|
|
less time, and so on.
|
|
|
|
However, simplification is not vital; if you do not want to do this,
|
|
report the bug anyway and send us the entire test case you used.
|
|
|
|
<LI>
|
|
|
|
A patch for the bug.
|
|
|
|
A patch for the bug does help us if it is a good one. But do not omit
|
|
the necessary information, such as the test case, on the assumption that
|
|
a patch is all we need. We might see problems with your patch and decide
|
|
to fix the problem another way, or we might not understand it at all.
|
|
|
|
Sometimes with a program as complicated as <CODE>ld</CODE> it is very hard to
|
|
construct an example that will make the program follow a certain path
|
|
through the code. If you do not send us the example, we will not be
|
|
able to construct one, so we will not be able to verify that the bug is
|
|
fixed.
|
|
|
|
And if we cannot understand what bug you are trying to fix, or why your
|
|
patch should be an improvement, we will not install it. A test case will
|
|
help us to understand.
|
|
|
|
<LI>
|
|
|
|
A guess about what the bug is or what it depends on.
|
|
|
|
Such guesses are usually wrong. Even we cannot guess right about such
|
|
things without first using the debugger to find the facts.
|
|
</UL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC37" HREF="ld.html#TOC37">MRI Compatible Script Files</A></H1>
|
|
<P>
|
|
<A NAME="IDX385"></A>
|
|
To aid users making the transition to GNU <CODE>ld</CODE> from the MRI
|
|
linker, <CODE>ld</CODE> can use MRI compatible linker scripts as an
|
|
alternative to the more general-purpose linker scripting language
|
|
described in section <A HREF="ld.html#SEC5">Command Language</A>. MRI compatible linker
|
|
scripts have a much simpler command set than the scripting language
|
|
otherwise used with <CODE>ld</CODE>. GNU <CODE>ld</CODE> supports the most
|
|
commonly used MRI linker commands; these commands are described here.
|
|
|
|
</P>
|
|
<P>
|
|
In general, MRI scripts aren't of much use with the <CODE>a.out</CODE> object
|
|
file format, since it only has three sections and MRI scripts lack some
|
|
features to make use of them.
|
|
|
|
</P>
|
|
<P>
|
|
You can specify a file containing an MRI-compatible script using the
|
|
<SAMP>`-c'</SAMP> command-line option.
|
|
|
|
</P>
|
|
<P>
|
|
Each command in an MRI-compatible script occupies its own line; each
|
|
command line starts with the keyword that identifies the command (though
|
|
blank lines are also allowed for punctuation). If a line of an
|
|
MRI-compatible script begins with an unrecognized keyword, <CODE>ld</CODE>
|
|
issues a warning message, but continues processing the script.
|
|
|
|
</P>
|
|
<P>
|
|
Lines beginning with <SAMP>`*'</SAMP> are comments.
|
|
|
|
</P>
|
|
<P>
|
|
You can write these commands using all upper-case letters, or all
|
|
lower case; for example, <SAMP>`chip'</SAMP> is the same as <SAMP>`CHIP'</SAMP>.
|
|
The following list shows only the upper-case form of each command.
|
|
|
|
</P>
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>ABSOLUTE <VAR>secname</VAR></CODE>
|
|
<DD>
|
|
<A NAME="IDX386"></A>
|
|
|
|
<DT><CODE>ABSOLUTE <VAR>secname</VAR>, <VAR>secname</VAR>, ... <VAR>secname</VAR></CODE>
|
|
<DD>
|
|
Normally, <CODE>ld</CODE> includes in the output file all sections from all
|
|
the input files. However, in an MRI-compatible script, you can use the
|
|
<CODE>ABSOLUTE</CODE> command to restrict the sections that will be present in
|
|
your output program. If the <CODE>ABSOLUTE</CODE> command is used at all in a
|
|
script, then only the sections named explicitly in <CODE>ABSOLUTE</CODE>
|
|
commands will appear in the linker output. You can still use other
|
|
input sections (whatever you select on the command line, or using
|
|
<CODE>LOAD</CODE>) to resolve addresses in the output file.
|
|
|
|
<A NAME="IDX387"></A>
|
|
<DT><CODE>ALIAS <VAR>out-secname</VAR>, <VAR>in-secname</VAR></CODE>
|
|
<DD>
|
|
Use this command to place the data from input section <VAR>in-secname</VAR>
|
|
in a section called <VAR>out-secname</VAR> in the linker output file.
|
|
|
|
<VAR>in-secname</VAR> may be an integer.
|
|
|
|
<A NAME="IDX388"></A>
|
|
<DT><CODE>ALIGN <VAR>secname</VAR> = <VAR>expression</VAR></CODE>
|
|
<DD>
|
|
Align the section called <VAR>secname</VAR> to <VAR>expression</VAR>. The
|
|
<VAR>expression</VAR> should be a power of two.
|
|
|
|
<A NAME="IDX389"></A>
|
|
<DT><CODE>BASE <VAR>expression</VAR></CODE>
|
|
<DD>
|
|
Use the value of <VAR>expression</VAR> as the lowest address (other than
|
|
absolute addresses) in the output file.
|
|
|
|
<A NAME="IDX390"></A>
|
|
<DT><CODE>CHIP <VAR>expression</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>CHIP <VAR>expression</VAR>, <VAR>expression</VAR></CODE>
|
|
<DD>
|
|
This command does nothing; it is accepted only for compatibility.
|
|
|
|
<A NAME="IDX391"></A>
|
|
<DT><CODE>END</CODE>
|
|
<DD>
|
|
This command does nothing whatever; it's only accepted for compatibility.
|
|
|
|
<A NAME="IDX392"></A>
|
|
<DT><CODE>FORMAT <VAR>output-format</VAR></CODE>
|
|
<DD>
|
|
Similar to the <CODE>OUTPUT_FORMAT</CODE> command in the more general linker
|
|
language, but restricted to one of these output formats:
|
|
|
|
|
|
<OL>
|
|
<LI>
|
|
|
|
S-records, if <VAR>output-format</VAR> is <SAMP>`S'</SAMP>
|
|
|
|
<LI>
|
|
|
|
IEEE, if <VAR>output-format</VAR> is <SAMP>`IEEE'</SAMP>
|
|
|
|
<LI>
|
|
|
|
COFF (the <SAMP>`coff-m68k'</SAMP> variant in BFD), if <VAR>output-format</VAR> is
|
|
<SAMP>`COFF'</SAMP>
|
|
</OL>
|
|
|
|
<A NAME="IDX393"></A>
|
|
<DT><CODE>LIST <VAR>anything</VAR>...</CODE>
|
|
<DD>
|
|
Print (to the standard output file) a link map, as produced by the
|
|
<CODE>ld</CODE> command-line option <SAMP>`-M'</SAMP>.
|
|
|
|
The keyword <CODE>LIST</CODE> may be followed by anything on the
|
|
same line, with no change in its effect.
|
|
|
|
<A NAME="IDX394"></A>
|
|
<DT><CODE>LOAD <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>LOAD <VAR>filename</VAR>, <VAR>filename</VAR>, ... <VAR>filename</VAR></CODE>
|
|
<DD>
|
|
Include one or more object file <VAR>filename</VAR> in the link; this has the
|
|
same effect as specifying <VAR>filename</VAR> directly on the <CODE>ld</CODE>
|
|
command line.
|
|
|
|
<A NAME="IDX395"></A>
|
|
<DT><CODE>NAME <VAR>output-name</VAR></CODE>
|
|
<DD>
|
|
<VAR>output-name</VAR> is the name for the program produced by <CODE>ld</CODE>; the
|
|
MRI-compatible command <CODE>NAME</CODE> is equivalent to the command-line
|
|
option <SAMP>`-o'</SAMP> or the general script language command <CODE>OUTPUT</CODE>.
|
|
|
|
<A NAME="IDX396"></A>
|
|
<DT><CODE>ORDER <VAR>secname</VAR>, <VAR>secname</VAR>, ... <VAR>secname</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>ORDER <VAR>secname</VAR> <VAR>secname</VAR> <VAR>secname</VAR></CODE>
|
|
<DD>
|
|
Normally, <CODE>ld</CODE> orders the sections in its output file in the
|
|
order in which they first appear in the input files. In an MRI-compatible
|
|
script, you can override this ordering with the <CODE>ORDER</CODE> command. The
|
|
sections you list with <CODE>ORDER</CODE> will appear first in your output
|
|
file, in the order specified.
|
|
|
|
<A NAME="IDX397"></A>
|
|
<DT><CODE>PUBLIC <VAR>name</VAR>=<VAR>expression</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>PUBLIC <VAR>name</VAR>,<VAR>expression</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>PUBLIC <VAR>name</VAR> <VAR>expression</VAR></CODE>
|
|
<DD>
|
|
Supply a value (<VAR>expression</VAR>) for external symbol
|
|
<VAR>name</VAR> used in the linker input files.
|
|
|
|
<A NAME="IDX398"></A>
|
|
<DT><CODE>SECT <VAR>secname</VAR>, <VAR>expression</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>SECT <VAR>secname</VAR>=<VAR>expression</VAR></CODE>
|
|
<DD>
|
|
<DT><CODE>SECT <VAR>secname</VAR> <VAR>expression</VAR></CODE>
|
|
<DD>
|
|
You can use any of these three forms of the <CODE>SECT</CODE> command to
|
|
specify the start address (<VAR>expression</VAR>) for section <VAR>secname</VAR>.
|
|
If you have more than one <CODE>SECT</CODE> statement for the same
|
|
<VAR>secname</VAR>, only the <EM>first</EM> sets the start address.
|
|
</DL>
|
|
|
|
|
|
|
|
<H1><A NAME="SEC38" HREF="ld.html#TOC38">Index</A></H1>
|
|
|
|
<P>
|
|
Jump to:
|
|
<A HREF="#cindex_"">"</A>
|
|
-
|
|
<A HREF="#cindex_*">*</A>
|
|
-
|
|
<A HREF="#cindex_-">-</A>
|
|
-
|
|
<A HREF="#cindex_.">.</A>
|
|
-
|
|
<A HREF="#cindex_0">0</A>
|
|
-
|
|
<A HREF="#cindex_:">:</A>
|
|
-
|
|
<A HREF="#cindex_;">;</A>
|
|
-
|
|
<A HREF="#cindex_=">=</A>
|
|
-
|
|
<A HREF="#cindex_>">></A>
|
|
-
|
|
<A HREF="#cindex_[">[</A>
|
|
-
|
|
<A HREF="#cindex_a">a</A>
|
|
-
|
|
<A HREF="#cindex_b">b</A>
|
|
-
|
|
<A HREF="#cindex_c">c</A>
|
|
-
|
|
<A HREF="#cindex_d">d</A>
|
|
-
|
|
<A HREF="#cindex_e">e</A>
|
|
-
|
|
<A HREF="#cindex_f">f</A>
|
|
-
|
|
<A HREF="#cindex_g">g</A>
|
|
-
|
|
<A HREF="#cindex_h">h</A>
|
|
-
|
|
<A HREF="#cindex_i">i</A>
|
|
-
|
|
<A HREF="#cindex_k">k</A>
|
|
-
|
|
<A HREF="#cindex_l">l</A>
|
|
-
|
|
<A HREF="#cindex_m">m</A>
|
|
-
|
|
<A HREF="#cindex_n">n</A>
|
|
-
|
|
<A HREF="#cindex_o">o</A>
|
|
-
|
|
<A HREF="#cindex_p">p</A>
|
|
-
|
|
<A HREF="#cindex_q">q</A>
|
|
-
|
|
<A HREF="#cindex_r">r</A>
|
|
-
|
|
<A HREF="#cindex_s">s</A>
|
|
-
|
|
<A HREF="#cindex_t">t</A>
|
|
-
|
|
<A HREF="#cindex_u">u</A>
|
|
-
|
|
<A HREF="#cindex_v">v</A>
|
|
-
|
|
<A HREF="#cindex_w">w</A>
|
|
<P>
|
|
<H2><A NAME="cindex_"">"</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX211">"</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_*">*</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX278">*( COMMON )</A>
|
|
<LI><A HREF="ld.html#IDX274">*(<VAR>section</VAR>)</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_-">-</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX103">-(</A>
|
|
<LI><A HREF="ld.html#IDX10">--architecture=<VAR>arch</VAR></A>
|
|
<LI><A HREF="ld.html#IDX30">--auxiliary</A>
|
|
<LI><A HREF="ld.html#IDX115">--cref</A>
|
|
<LI><A HREF="ld.html#IDX117">--defsym <VAR>symbol</VAR>=<VAR>exp</VAR></A>
|
|
<LI><A HREF="ld.html#IDX92">--discard-all</A>
|
|
<LI><A HREF="ld.html#IDX95">--discard-locals</A>
|
|
<LI><A HREF="ld.html#IDX119">--dynamic-linker <VAR>file</VAR></A>
|
|
<LI><A HREF="ld.html#IDX126">--embedded-relocs</A>
|
|
<LI><A HREF="ld.html#IDX25">--entry=<VAR>entry</VAR></A>
|
|
<LI><A HREF="ld.html#IDX28">--export-dynamic</A>
|
|
<LI><A HREF="ld.html#IDX32">--filter</A>
|
|
<LI><A HREF="ld.html#IDX33">--force-exe-suffix</A>
|
|
<LI><A HREF="ld.html#IDX13">--format=<VAR>format</VAR></A>
|
|
<LI><A HREF="ld.html#IDX36">--gpsize</A>
|
|
<LI><A HREF="ld.html#IDX129">--help</A>
|
|
<LI><A HREF="ld.html#IDX70">--just-symbols=<VAR>file</VAR></A>
|
|
<LI><A HREF="ld.html#IDX48">--library-path=<VAR>dir</VAR></A>
|
|
<LI><A HREF="ld.html#IDX45">--library=<VAR>archive</VAR></A>
|
|
<LI><A HREF="ld.html#IDX17">--mri-script=<VAR>MRI-cmdfile</VAR></A>
|
|
<LI><A HREF="ld.html#IDX57">--nmagic</A>
|
|
<LI><A HREF="ld.html#IDX132">--no-keep-memory</A>
|
|
<LI><A HREF="ld.html#IDX133">--no-warn-mismatch</A>
|
|
<LI><A HREF="ld.html#IDX134">--no-whole-archive</A>
|
|
<LI><A HREF="ld.html#IDX136">--noinhibit-exec</A>
|
|
<LI><A HREF="ld.html#IDX137">--oformat</A>
|
|
<LI><A HREF="ld.html#IDX59">--omagic</A>
|
|
<LI><A HREF="ld.html#IDX63">--output=<VAR>output</VAR></A>
|
|
<LI><A HREF="ld.html#IDX53">--print-map</A>
|
|
<LI><A HREF="ld.html#IDX140">--relax</A>
|
|
<LI><A HREF="ld.html#IDX364"><CODE>--relax</CODE> on i960</A>
|
|
<LI><A HREF="ld.html#IDX68">--relocateable</A>
|
|
<LI><A HREF="ld.html#IDX82">--script=<VAR>script</VAR></A>
|
|
<LI><A HREF="ld.html#IDX153">--sort-common</A>
|
|
<LI><A HREF="ld.html#IDX154">--split-by-file</A>
|
|
<LI><A HREF="ld.html#IDX155">--split-by-reloc</A>
|
|
<LI><A HREF="ld.html#IDX156">--stats</A>
|
|
<LI><A HREF="ld.html#IDX73">--strip-all</A>
|
|
<LI><A HREF="ld.html#IDX76">--strip-debug</A>
|
|
<LI><A HREF="ld.html#IDX79">--trace</A>
|
|
<LI><A HREF="ld.html#IDX99">--trace-symbol=<VAR>symbol</VAR></A>
|
|
<LI><A HREF="ld.html#IDX157">--traditional-format</A>
|
|
<LI><A HREF="ld.html#IDX85">--undefined=<VAR>symbol</VAR></A>
|
|
<LI><A HREF="ld.html#IDX166">--verbose</A>
|
|
<LI><A HREF="ld.html#IDX89">--version</A>
|
|
<LI><A HREF="ld.html#IDX168">--version-script=<VAR>version-scriptfile</VAR></A>
|
|
<LI><A HREF="ld.html#IDX170">--warn-comon</A>
|
|
<LI><A HREF="ld.html#IDX173">--warn-constructors</A>
|
|
<LI><A HREF="ld.html#IDX174">--warn-multiple-gp</A>
|
|
<LI><A HREF="ld.html#IDX175">--warn-once</A>
|
|
<LI><A HREF="ld.html#IDX178">--warn-section-align</A>
|
|
<LI><A HREF="ld.html#IDX181">--whole-archive</A>
|
|
<LI><A HREF="ld.html#IDX183">--wrap</A>
|
|
<LI><A HREF="ld.html#IDX9">-A<VAR>arch</VAR></A>
|
|
<LI><A HREF="ld.html#IDX7">-a<VAR>keyword</VAR></A>
|
|
<LI><A HREF="ld.html#IDX105">-assert <VAR>keyword</VAR></A>
|
|
<LI><A HREF="ld.html#IDX12">-b <VAR>format</VAR></A>
|
|
<LI><A HREF="ld.html#IDX106">-Bdynamic</A>
|
|
<LI><A HREF="ld.html#IDX151">-Bshareable</A>
|
|
<LI><A HREF="ld.html#IDX109">-Bstatic</A>
|
|
<LI><A HREF="ld.html#IDX113">-Bsymbolic</A>
|
|
<LI><A HREF="ld.html#IDX16">-c <VAR>MRI-cmdfile</VAR></A>
|
|
<LI><A HREF="ld.html#IDX108">-call_shared</A>
|
|
<LI><A HREF="ld.html#IDX20">-d</A>
|
|
<LI><A HREF="ld.html#IDX21">-dc</A>
|
|
<LI><A HREF="ld.html#IDX110">-dn</A>
|
|
<LI><A HREF="ld.html#IDX22">-dp</A>
|
|
<LI><A HREF="ld.html#IDX107">-dy</A>
|
|
<LI><A HREF="ld.html#IDX27">-E</A>
|
|
<LI><A HREF="ld.html#IDX24">-e <VAR>entry</VAR></A>
|
|
<LI><A HREF="ld.html#IDX122">-EB</A>
|
|
<LI><A HREF="ld.html#IDX124">-EL</A>
|
|
<LI><A HREF="ld.html#IDX31">-F</A>
|
|
<LI><A HREF="ld.html#IDX29">-f</A>
|
|
<LI><A HREF="ld.html#IDX35">-G</A>
|
|
<LI><A HREF="ld.html#IDX34">-g</A>
|
|
<LI><A HREF="ld.html#IDX39">-h<VAR>name</VAR></A>
|
|
<LI><A HREF="ld.html#IDX41">-i</A>
|
|
<LI><A HREF="ld.html#IDX44">-l<VAR>archive</VAR></A>
|
|
<LI><A HREF="ld.html#IDX47">-L<VAR>dir</VAR></A>
|
|
<LI><A HREF="ld.html#IDX52">-M</A>
|
|
<LI><A HREF="ld.html#IDX50">-m <VAR>emulation</VAR></A>
|
|
<LI><A HREF="ld.html#IDX130">-Map</A>
|
|
<LI><A HREF="ld.html#IDX58">-N</A>
|
|
<LI><A HREF="ld.html#IDX54">-n</A>
|
|
<LI><A HREF="ld.html#IDX111">-non_shared</A>
|
|
<LI><A HREF="ld.html#IDX62">-o <VAR>output</VAR></A>
|
|
<LI><A HREF="ld.html#IDX138">-qmagic</A>
|
|
<LI><A HREF="ld.html#IDX139">-Qy</A>
|
|
<LI><A HREF="ld.html#IDX67">-r</A>
|
|
<LI><A HREF="ld.html#IDX69">-R <VAR>file</VAR></A>
|
|
<LI><A HREF="ld.html#IDX147">-rpath</A>
|
|
<LI><A HREF="ld.html#IDX149">-rpath-link</A>
|
|
<LI><A HREF="ld.html#IDX75">-S</A>
|
|
<LI><A HREF="ld.html#IDX72">-s</A>
|
|
<LI><A HREF="ld.html#IDX150">-shared</A>
|
|
<LI><A HREF="ld.html#IDX40">-soname=<VAR>name</VAR></A>
|
|
<LI><A HREF="ld.html#IDX112">-static</A>
|
|
<LI><A HREF="ld.html#IDX78">-t</A>
|
|
<LI><A HREF="ld.html#IDX81">-T <VAR>script</VAR></A>
|
|
<LI><A HREF="ld.html#IDX160">-Tbss <VAR>org</VAR></A>
|
|
<LI><A HREF="ld.html#IDX161">-Tdata <VAR>org</VAR></A>
|
|
<LI><A HREF="ld.html#IDX162">-Ttext <VAR>org</VAR></A>
|
|
<LI><A HREF="ld.html#IDX84">-u <VAR>symbol</VAR></A>
|
|
<LI><A HREF="ld.html#IDX164">-Ur</A>
|
|
<LI><A HREF="ld.html#IDX88">-V</A>
|
|
<LI><A HREF="ld.html#IDX87">-v</A>
|
|
<LI><A HREF="ld.html#IDX94">-X</A>
|
|
<LI><A HREF="ld.html#IDX91">-x</A>
|
|
<LI><A HREF="ld.html#IDX101">-Y <VAR>path</VAR></A>
|
|
<LI><A HREF="ld.html#IDX98">-y <VAR>symbol</VAR></A>
|
|
<LI><A HREF="ld.html#IDX102">-z <VAR>keyword</VAR></A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_.">.</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX212">.</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_0">0</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX201">0x</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_:">:</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX311">:<VAR>phdr</VAR></A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_;">;</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX225">;</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_=">=</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX314">=<VAR>fill</VAR></A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_>">></A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX308">><VAR>region</VAR></A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_[">[</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX275"><CODE>[<VAR>section</VAR>...]</CODE>, not supported</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_a">a</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX386"><CODE>ABSOLUTE</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX227">absolute and relocatable symbols</A>
|
|
<LI><A HREF="ld.html#IDX233">ABSOLUTE(<VAR>exp</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX235">ADDR(<VAR>section</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX387"><CODE>ALIAS</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX388"><CODE>ALIGN</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX239">ALIGN(<VAR>exp</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX301">aligning sections</A>
|
|
<LI><A HREF="ld.html#IDX255">allocating memory</A>
|
|
<LI><A HREF="ld.html#IDX8">architectures</A>
|
|
<LI><A HREF="ld.html#IDX43">archive files, from cmd line</A>
|
|
<LI><A HREF="ld.html#IDX196">arithmetic</A>
|
|
<LI><A HREF="ld.html#IDX218">arithmetic operators</A>
|
|
<LI><A HREF="ld.html#IDX222">assignment in scripts</A>
|
|
<LI><A HREF="ld.html#IDX285">assignment, in section defn</A>
|
|
<LI><A HREF="ld.html#IDX305">AT ( <VAR>ldadr</VAR> )</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_b">b</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX366">back end</A>
|
|
<LI><A HREF="ld.html#IDX389"><CODE>BASE</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX373">BFD canonical format</A>
|
|
<LI><A HREF="ld.html#IDX370">BFD requirements</A>
|
|
<LI><A HREF="ld.html#IDX120">big-endian objects</A>
|
|
<LI><A HREF="ld.html#IDX340">binary input files</A>
|
|
<LI><A HREF="ld.html#IDX11">binary input format</A>
|
|
<LI><A HREF="ld.html#IDX299">BLOCK(<VAR>align</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX377">bug criteria</A>
|
|
<LI><A HREF="ld.html#IDX383">bug reports</A>
|
|
<LI><A HREF="ld.html#IDX375">bugs in <CODE>ld</CODE></A>
|
|
<LI><A HREF="ld.html#IDX286">BYTE(<VAR>expression</VAR>)</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_c">c</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX331">C++ constructors, arranging in link</A>
|
|
<LI><A HREF="ld.html#IDX390"><CODE>CHIP</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX172">combining symbols, warnings on</A>
|
|
<LI><A HREF="ld.html#IDX189">command files</A>
|
|
<LI><A HREF="ld.html#IDX3">command line</A>
|
|
<LI><A HREF="ld.html#IDX191">commands, fundamental</A>
|
|
<LI><A HREF="ld.html#IDX194">comments</A>
|
|
<LI><A HREF="ld.html#IDX19">common allocation</A>, <A HREF="ld.html#IDX336">common allocation</A>
|
|
<LI><A HREF="ld.html#IDX277">commons in output</A>
|
|
<LI><A HREF="ld.html#IDX18">compatibility, MRI</A>
|
|
<LI><A HREF="ld.html#IDX330">CONSTRUCTORS</A>
|
|
<LI><A HREF="ld.html#IDX165">constructors</A>
|
|
<LI><A HREF="ld.html#IDX332">constructors, arranging in link</A>
|
|
<LI><A HREF="ld.html#IDX267">contents of a section</A>
|
|
<LI><A HREF="ld.html#IDX380">crash of linker</A>
|
|
<LI><A HREF="ld.html#IDX282">CREATE_OBJECT_SYMBOLS</A>
|
|
<LI><A HREF="ld.html#IDX114">cross reference table</A>
|
|
<LI><A HREF="ld.html#IDX357">cross references</A>
|
|
<LI><A HREF="ld.html#IDX215">current output location</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_d">d</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX159">dbx</A>
|
|
<LI><A HREF="ld.html#IDX199">decimal integers</A>
|
|
<LI><A HREF="ld.html#IDX187">default emulation</A>
|
|
<LI><A HREF="ld.html#IDX185">default input format</A>
|
|
<LI><A HREF="ld.html#IDX241">DEFINED(<VAR>symbol</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX93">deleting local symbols</A>
|
|
<LI><A HREF="ld.html#IDX291">direct output</A>
|
|
<LI><A HREF="ld.html#IDX254">discontinuous memory</A>
|
|
<LI><A HREF="ld.html#IDX213">dot</A>
|
|
<LI><A HREF="ld.html#IDX118">dynamic linker, from command line</A>
|
|
<LI><A HREF="ld.html#IDX26">dynamic symbol table</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_e">e</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX321">ELF program headers</A>
|
|
<LI><A HREF="ld.html#IDX49">emulation</A>
|
|
<LI><A HREF="ld.html#IDX188">emulation, default</A>
|
|
<LI><A HREF="ld.html#IDX391"><CODE>END</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX121">endianness</A>
|
|
<LI><A HREF="ld.html#IDX325">entry point, defaults</A>
|
|
<LI><A HREF="ld.html#IDX23">entry point, from command line</A>
|
|
<LI><A HREF="ld.html#IDX322">ENTRY(<VAR>symbol</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX381">error on valid input</A>
|
|
<LI><A HREF="ld.html#IDX221">expression evaluation order</A>
|
|
<LI><A HREF="ld.html#IDX195">expression syntax</A>
|
|
<LI><A HREF="ld.html#IDX234">expression, absolute</A>
|
|
<LI><A HREF="ld.html#IDX279">expressions in a section</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_f">f</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX378">fatal signal</A>
|
|
<LI><A HREF="ld.html#IDX268"><VAR>filename</VAR></A>
|
|
<LI><A HREF="ld.html#IDX281">filename symbols</A>
|
|
<LI><A HREF="ld.html#IDX271"><VAR>filename</VAR>(<VAR>section</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX272">files and sections, section defn</A>
|
|
<LI><A HREF="ld.html#IDX270">files, including in output sections</A>
|
|
<LI><A HREF="ld.html#IDX316">fill pattern, entire section</A>
|
|
<LI><A HREF="ld.html#IDX292">FILL(<VAR>expression</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX353">first input file</A>
|
|
<LI><A HREF="ld.html#IDX324">first instruction</A>
|
|
<LI><A HREF="ld.html#IDX333">FLOAT</A>
|
|
<LI><A HREF="ld.html#IDX335">FORCE_COMMON_ALLOCATION</A>
|
|
<LI><A HREF="ld.html#IDX392"><CODE>FORMAT</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX348">format, output file</A>
|
|
<LI><A HREF="ld.html#IDX232">functions in expression language</A>
|
|
<LI><A HREF="ld.html#IDX190">fundamental script commands</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_g">g</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX1">GNU linker</A>
|
|
<LI><A HREF="ld.html#IDX184">GNUTARGET</A>, <A HREF="ld.html#IDX356">GNUTARGET</A>
|
|
<LI><A HREF="ld.html#IDX341">GROUP ( <VAR>files</VAR> )</A>
|
|
<LI><A HREF="ld.html#IDX342">grouping input files</A>
|
|
<LI><A HREF="ld.html#IDX104">groups of archives</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_h">h</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX360">H8/300 support</A>
|
|
<LI><A HREF="ld.html#IDX248">header size</A>
|
|
<LI><A HREF="ld.html#IDX127">help</A>
|
|
<LI><A HREF="ld.html#IDX200">hexadecimal integers</A>
|
|
<LI><A HREF="ld.html#IDX216">holes</A>
|
|
<LI><A HREF="ld.html#IDX293">holes, filling</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_i">i</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX363">i960 support</A>
|
|
<LI><A HREF="ld.html#IDX337">INCLUDE <VAR>filename</VAR></A>
|
|
<LI><A HREF="ld.html#IDX338">including a linker script</A>
|
|
<LI><A HREF="ld.html#IDX182">including an entire archive</A>
|
|
<LI><A HREF="ld.html#IDX42">incremental link</A>
|
|
<LI><A HREF="ld.html#IDX339">INPUT ( <VAR>files</VAR> )</A>
|
|
<LI><A HREF="ld.html#IDX354">input file format</A>
|
|
<LI><A HREF="ld.html#IDX280">input filename symbols</A>
|
|
<LI><A HREF="ld.html#IDX80">input files, displaying</A>
|
|
<LI><A HREF="ld.html#IDX269">input files, section defn</A>
|
|
<LI><A HREF="ld.html#IDX14">input format</A>, <A HREF="ld.html#IDX15">input format</A>
|
|
<LI><A HREF="ld.html#IDX273">input sections to output section</A>
|
|
<LI><A HREF="ld.html#IDX197">integer notation</A>
|
|
<LI><A HREF="ld.html#IDX207">integer suffixes</A>
|
|
<LI><A HREF="ld.html#IDX374">internal object-file format</A>
|
|
<LI><A HREF="ld.html#IDX382">invalid input</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_k">k</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX204">K and M integer suffixes</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_l">l</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX263">l =</A>
|
|
<LI><A HREF="ld.html#IDX97">L, deleting symbols beginning</A>
|
|
<LI><A HREF="ld.html#IDX193">layout of output file</A>
|
|
<LI><A HREF="ld.html#IDX220">lazy evaluation</A>
|
|
<LI><A HREF="ld.html#IDX384"><CODE>ld</CODE> bugs, reporting</A>
|
|
<LI><A HREF="ld.html#IDX186">LDEMULATION</A>
|
|
<LI><A HREF="ld.html#IDX262">len =</A>
|
|
<LI><A HREF="ld.html#IDX261">LENGTH =</A>
|
|
<LI><A HREF="ld.html#IDX51">link map</A>
|
|
<LI><A HREF="ld.html#IDX148">link-time runtime library search path</A>
|
|
<LI><A HREF="ld.html#IDX379">linker crash</A>
|
|
<LI><A HREF="ld.html#IDX393"><CODE>LIST</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX123">little-endian objects</A>
|
|
<LI><A HREF="ld.html#IDX394"><CODE>LOAD</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX307">load address, specifying</A>
|
|
<LI><A HREF="ld.html#IDX237">LOADADDR(<VAR>section</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX304">loading, preventing</A>
|
|
<LI><A HREF="ld.html#IDX96">local symbols, deleting</A>
|
|
<LI><A HREF="ld.html#IDX214">location counter</A>
|
|
<LI><A HREF="ld.html#IDX288">LONG(<VAR>expression</VAR>)</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_m">m</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX205">M and K integer suffixes</A>
|
|
<LI><A HREF="ld.html#IDX346">machine architecture, output</A>
|
|
<LI><A HREF="ld.html#IDX359">machine dependencies</A>
|
|
<LI><A HREF="ld.html#IDX250">MAX</A>
|
|
<LI><A HREF="ld.html#IDX252">MEMORY</A>
|
|
<LI><A HREF="ld.html#IDX257">memory region attributes</A>
|
|
<LI><A HREF="ld.html#IDX310">memory regions and sections</A>
|
|
<LI><A HREF="ld.html#IDX131">memory usage</A>
|
|
<LI><A HREF="ld.html#IDX251">MIN</A>
|
|
<LI><A HREF="ld.html#IDX125">MIPS embedded PIC code</A>
|
|
<LI><A HREF="ld.html#IDX385">MRI compatibility</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_n">n</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX395"><CODE>NAME</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX209">names</A>
|
|
<LI><A HREF="ld.html#IDX256">naming memory regions</A>
|
|
<LI><A HREF="ld.html#IDX266">naming output sections</A>
|
|
<LI><A HREF="ld.html#IDX64">naming the output file</A>, <A HREF="ld.html#IDX344">naming the output file</A>
|
|
<LI><A HREF="ld.html#IDX202">negative integers</A>
|
|
<LI><A HREF="ld.html#IDX243">NEXT(<VAR>exp</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX56">NMAGIC</A>
|
|
<LI><A HREF="ld.html#IDX358">NOCROSSREFS ( <VAR>sections</VAR> )</A>
|
|
<LI><A HREF="ld.html#IDX334">NOFLOAT</A>
|
|
<LI><A HREF="ld.html#IDX302">NOLOAD</A>
|
|
<LI><A HREF="ld.html#IDX230">Non constant expression</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_o">o</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX259">o =</A>
|
|
<LI><A HREF="ld.html#IDX369">objdump -i</A>
|
|
<LI><A HREF="ld.html#IDX367">object file management</A>
|
|
<LI><A HREF="ld.html#IDX6">object files</A>
|
|
<LI><A HREF="ld.html#IDX368">object formats available</A>
|
|
<LI><A HREF="ld.html#IDX37">object size</A>
|
|
<LI><A HREF="ld.html#IDX198">octal integers</A>
|
|
<LI><A HREF="ld.html#IDX61">OMAGIC</A>
|
|
<LI><A HREF="ld.html#IDX372">opening object files</A>
|
|
<LI><A HREF="ld.html#IDX217">Operators for arithmetic</A>
|
|
<LI><A HREF="ld.html#IDX4">options</A>
|
|
<LI><A HREF="ld.html#IDX396"><CODE>ORDER</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX260">org =</A>
|
|
<LI><A HREF="ld.html#IDX258">ORIGIN =</A>
|
|
<LI><A HREF="ld.html#IDX343">OUTPUT ( <VAR>filename</VAR> )</A>
|
|
<LI><A HREF="ld.html#IDX135">output file after errors</A>
|
|
<LI><A HREF="ld.html#IDX192">output file layout</A>
|
|
<LI><A HREF="ld.html#IDX345">OUTPUT_ARCH ( <VAR>bfdname</VAR> )</A>
|
|
<LI><A HREF="ld.html#IDX347">OUTPUT_FORMAT ( <VAR>bfdname</VAR> )</A>
|
|
<LI><A HREF="ld.html#IDX317">OVERLAY</A>
|
|
<LI><A HREF="ld.html#IDX318">overlays</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_p">p</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX65">partial link</A>
|
|
<LI><A HREF="ld.html#IDX350">path for libraries</A>
|
|
<LI><A HREF="ld.html#IDX319">PHDRS</A>
|
|
<LI><A HREF="ld.html#IDX219">precedence in expressions</A>
|
|
<LI><A HREF="ld.html#IDX303">prevent unnecessary loading</A>
|
|
<LI><A HREF="ld.html#IDX320">program headers</A>
|
|
<LI><A HREF="ld.html#IDX313">program headers and sections</A>
|
|
<LI><A HREF="ld.html#IDX231">provide</A>
|
|
<LI><A HREF="ld.html#IDX397"><CODE>PUBLIC</CODE> (MRI)</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_q">q</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX289">QUAD(<VAR>expression</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX210">quoted symbol names</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_r">r</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX55">read-only text</A>
|
|
<LI><A HREF="ld.html#IDX60">read/write from cmd line</A>
|
|
<LI><A HREF="ld.html#IDX253">regions of memory</A>
|
|
<LI><A HREF="ld.html#IDX142">relaxing addressing modes</A>
|
|
<LI><A HREF="ld.html#IDX361">relaxing on H8/300</A>
|
|
<LI><A HREF="ld.html#IDX365">relaxing on i960</A>
|
|
<LI><A HREF="ld.html#IDX228">relocatable and absolute symbols</A>
|
|
<LI><A HREF="ld.html#IDX66">relocatable output</A>
|
|
<LI><A HREF="ld.html#IDX376">reporting bugs in <CODE>ld</CODE></A>
|
|
<LI><A HREF="ld.html#IDX371">requirements for BFD</A>
|
|
<LI><A HREF="ld.html#IDX143">retaining specified symbols</A>
|
|
<LI><A HREF="ld.html#IDX240">rounding up location counter</A>
|
|
<LI><A HREF="ld.html#IDX38">runtime library name</A>
|
|
<LI><A HREF="ld.html#IDX146">runtime library search path</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_s">s</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX203">scaled integers</A>
|
|
<LI><A HREF="ld.html#IDX83">script files</A>
|
|
<LI><A HREF="ld.html#IDX46">search directory, from cmd line</A>
|
|
<LI><A HREF="ld.html#IDX351">search path, libraries</A>
|
|
<LI><A HREF="ld.html#IDX349">SEARCH_DIR ( <VAR>path</VAR> )</A>
|
|
<LI><A HREF="ld.html#IDX398"><CODE>SECT</CODE> (MRI)</A>
|
|
<LI><A HREF="ld.html#IDX236">section address</A>, <A HREF="ld.html#IDX298">section address</A>
|
|
<LI><A HREF="ld.html#IDX300">section alignment</A>
|
|
<LI><A HREF="ld.html#IDX180">section alignment, warnings on</A>
|
|
<LI><A HREF="ld.html#IDX265">section definition</A>
|
|
<LI><A HREF="ld.html#IDX295">section defn, full syntax</A>
|
|
<LI><A HREF="ld.html#IDX315">section fill pattern</A>
|
|
<LI><A HREF="ld.html#IDX238">section load address</A>
|
|
<LI><A HREF="ld.html#IDX246">section size</A>
|
|
<LI><A HREF="ld.html#IDX297">section start</A>
|
|
<LI><A HREF="ld.html#IDX309">section, assigning to memory region</A>
|
|
<LI><A HREF="ld.html#IDX312">section, assigning to program header</A>
|
|
<LI><A HREF="ld.html#IDX264">SECTIONS</A>
|
|
<LI><A HREF="ld.html#IDX163">segment origins, cmd line</A>
|
|
<LI><A HREF="ld.html#IDX226">semicolon</A>
|
|
<LI><A HREF="ld.html#IDX152">shared libraries</A>
|
|
<LI><A HREF="ld.html#IDX287">SHORT(<VAR>expression</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX245">SIZEOF(<VAR>section</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX249">sizeof_headers</A>
|
|
<LI><A HREF="ld.html#IDX247">SIZEOF_HEADERS</A>
|
|
<LI><A HREF="ld.html#IDX306">specify load address</A>
|
|
<LI><A HREF="ld.html#IDX290">SQUAD(<VAR>expression</VAR>)</A>
|
|
<LI><A HREF="ld.html#IDX5">standard Unix system</A>
|
|
<LI><A HREF="ld.html#IDX296">start address, section</A>
|
|
<LI><A HREF="ld.html#IDX323">start of execution</A>
|
|
<LI><A HREF="ld.html#IDX352">STARTUP ( <VAR>filename</VAR> )</A>
|
|
<LI><A HREF="ld.html#IDX74">strip all symbols</A>
|
|
<LI><A HREF="ld.html#IDX77">strip debugger symbols</A>
|
|
<LI><A HREF="ld.html#IDX144">stripping all but some symbols</A>
|
|
<LI><A HREF="ld.html#IDX206">suffixes for integers</A>
|
|
<LI><A HREF="ld.html#IDX242">symbol defaults</A>
|
|
<LI><A HREF="ld.html#IDX223">symbol definition, scripts</A>
|
|
<LI><A HREF="ld.html#IDX208">symbol names</A>
|
|
<LI><A HREF="ld.html#IDX100">symbol tracing</A>
|
|
<LI><A HREF="ld.html#IDX327">symbol versions</A>
|
|
<LI><A HREF="ld.html#IDX71">symbol-only input</A>
|
|
<LI><A HREF="ld.html#IDX283"><VAR>symbol</VAR> = <VAR>expression</VAR> ;</A>
|
|
<LI><A HREF="ld.html#IDX284"><VAR>symbol</VAR> <VAR>f</VAR>= <VAR>expression</VAR> ;</A>
|
|
<LI><A HREF="ld.html#IDX116">symbols, from command line</A>
|
|
<LI><A HREF="ld.html#IDX229">symbols, relocatable and absolute</A>
|
|
<LI><A HREF="ld.html#IDX145">symbols, retaining selectively</A>
|
|
<LI><A HREF="ld.html#IDX141">synthesizing linker</A>
|
|
<LI><A HREF="ld.html#IDX362">synthesizing on H8/300</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_t">t</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX355">TARGET ( <VAR>format</VAR> )</A>
|
|
<LI><A HREF="ld.html#IDX158">traditional format</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_u">u</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX244">unallocated address, next</A>
|
|
<LI><A HREF="ld.html#IDX86">undefined symbol</A>
|
|
<LI><A HREF="ld.html#IDX177">undefined symbols, warnings on</A>
|
|
<LI><A HREF="ld.html#IDX276">uninitialized data</A>
|
|
<LI><A HREF="ld.html#IDX294">unspecified memory</A>
|
|
<LI><A HREF="ld.html#IDX128">usage</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_v">v</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX224">variables, defining</A>
|
|
<LI><A HREF="ld.html#IDX167">verbose</A>
|
|
<LI><A HREF="ld.html#IDX90">version</A>
|
|
<LI><A HREF="ld.html#IDX328">version script</A>
|
|
<LI><A HREF="ld.html#IDX169">version script, symbol versions</A>
|
|
<LI><A HREF="ld.html#IDX326">VERSION {script text}</A>
|
|
<LI><A HREF="ld.html#IDX329">versions of symbols</A>
|
|
</DIR>
|
|
<H2><A NAME="cindex_w">w</A></H2>
|
|
<DIR>
|
|
<LI><A HREF="ld.html#IDX171">warnings, on combining symbols</A>
|
|
<LI><A HREF="ld.html#IDX179">warnings, on section alignment</A>
|
|
<LI><A HREF="ld.html#IDX176">warnings, on undefined symbols</A>
|
|
<LI><A HREF="ld.html#IDX2">what is this?</A>
|
|
</DIR>
|
|
|
|
</P>
|
|
|
|
<P><HR><P>
|
|
This document was generated on 7 November 1998 using the
|
|
<A HREF="http://wwwinfo.cern.ch/dis/texi2html/">texi2html</A>
|
|
translator version 1.52.</P>
|
|
</BODY>
|
|
</HTML>
|