1015 lines
36 KiB
TeX
Executable File
1015 lines
36 KiB
TeX
Executable File
\input texinfo
|
|
@parindent=0pt
|
|
@setfilename gld
|
|
@c @@setchapternewpage odd
|
|
@settitle GLD, The GNU linker
|
|
@titlepage
|
|
@title{gld}
|
|
@subtitle{The gnu loader}
|
|
@sp 1
|
|
@subtitle Second Edition---gld version 2.0
|
|
@subtitle January 1991
|
|
@vskip 0pt plus 1filll
|
|
Copyright @copyright{} 1991 Free Software Foundation, Inc.
|
|
|
|
Permission is granted to make and distribute verbatim copies of
|
|
this manual provided the copyright notice and this permission notice
|
|
are preserved on all copies.
|
|
|
|
Permission is granted to copy and distribute modified versions of this
|
|
manual under the conditions for verbatim copying, provided also that
|
|
the entire resulting derived work is distributed under the terms of a
|
|
permission notice identical to this one.
|
|
|
|
Permission is granted to copy and distribute translations of this manual
|
|
into another language, under the above conditions for modified versions.
|
|
|
|
@author {Steve Chamberlain}
|
|
@author {Cygnus Support}
|
|
@author {steve@@cygnus.com}
|
|
@end titlepage
|
|
|
|
@node Top,,,
|
|
@comment node-name, next, previous, up
|
|
@ifinfo
|
|
This file documents the GNU linker gld.
|
|
@end ifinfo
|
|
|
|
@c chapter What does a linker do ?
|
|
@c chapter Command Language
|
|
@noindent
|
|
@chapter Overview
|
|
|
|
|
|
The @code{gld} command combines a number of object and archive files,
|
|
relocates their data and ties up symbol references. Often the last
|
|
step in building a new compiled program to run is a call to @code{gld}.
|
|
|
|
The @code{gld} command accepts Linker Command Language files in
|
|
a superset of AT+T's Link Editor Command Language syntax,
|
|
to provide explict and total control over the linking process.
|
|
|
|
This version of @code{gld} uses the general purpose @code{bfd} libraries
|
|
to operate on object files. This allows @code{gld} to read and
|
|
write any of the formats supported by @code{bfd}, different
|
|
formats may be linked together producing any available object file.
|
|
|
|
Supported formats:
|
|
@itemize @bullet
|
|
@item
|
|
Sun3 68k a.out
|
|
@item
|
|
IEEE-695 68k Object Module Format
|
|
@item
|
|
Oasys 68k Binary Relocatable Object File Format
|
|
@item
|
|
Sun4 sparc a.out
|
|
@item
|
|
88k bcs coff
|
|
@item
|
|
i960 coff little endian
|
|
@item
|
|
i960 coff big endian
|
|
@item
|
|
i960 b.out little endian
|
|
@item
|
|
i960 b.out big endian
|
|
@item
|
|
s-records
|
|
@end itemize
|
|
|
|
When linking similar formats, @code{gld} maintains all debugging
|
|
information.
|
|
|
|
@chapter Command line options
|
|
|
|
@example
|
|
gld [ -Bstatic ] [ -D @var{datasize} ]
|
|
[ -c @var{filename} ]
|
|
[ -d ] | [ -dc ] | [ -dp ]
|
|
[ -i ]
|
|
[ -e @var{entry} ] [ -l @var{arch} ] [ -L @var{searchdir} ] [ -M ]
|
|
[ -N | -n | -z ] [ -noinhibit-exec ] [ -r ] [ -S ] [ -s ]
|
|
[ -f @var{fill} ]
|
|
[ -T @var{textorg} ] [ -Tdata @var{dataorg} ] [ -t ] [ -u @var{sym}]
|
|
[ -X ] [ -x ]
|
|
[-o @var{output} ] @var{objfiles}@dots{}
|
|
@end example
|
|
|
|
Command-line options to GNU @code{gld} may be specified in any order, and
|
|
may be repeated at will. For the most part, repeating an option with a
|
|
different argument will either have no further effect, or override prior
|
|
occurrences (those further to the left on the command line) of an
|
|
option.
|
|
|
|
The exceptions which may meaningfully be present several times
|
|
are @code{-L}, @code{-l}, and @code{-u}.
|
|
|
|
@var{objfiles} may follow, precede, or be mixed in with
|
|
command-line options; save that an @var{objfiles} argument may not be
|
|
placed between an option flag and its argument.
|
|
|
|
Option arguments must follow the option letter without intervening
|
|
whitespace, or be given as separate arguments immediately following the
|
|
option that requires them.
|
|
|
|
@table @code
|
|
@item @var{objfiles}@dots{}
|
|
The object files @var{objfiles} to be linked; at least one must be specified.
|
|
|
|
@item -Bstatic
|
|
This flag is accepted for command-line compatibility with the SunOS linker,
|
|
but has no effect on @code{gld}.
|
|
|
|
@item -c @var{commandfile}
|
|
Directs @code{gld} to read linkage commands from the file @var{commandfile}.
|
|
|
|
@item -D @var{datasize}
|
|
Use this option to specify a target size for the @code{data} segment of
|
|
your linked program. The option is only obeyed if @var{datasize} is
|
|
larger than the natural size of the program's @code{data} segment.
|
|
|
|
@var{datasize} must be an integer specified in hexadecimal.
|
|
|
|
@code{ld} will simply increase the size of the @code{data} segment,
|
|
padding the created gap with zeros, and reduce the size of the
|
|
@code{bss} segment to match.
|
|
|
|
@item -d
|
|
Force @code{ld} to assign space to common symbols
|
|
even if a relocatable output file is specified (@code{-r}).
|
|
|
|
@item -dc | -dp
|
|
This flags is accepted for command-line compatibility with the SunOS linker,
|
|
but has no effect on @code{gld}.
|
|
|
|
@item -e @var{entry}
|
|
Use @var{entry} as the explicit symbol for beginning execution of your
|
|
program, rather than the default entry point. If this symbol is
|
|
not specified, the symbol @code{start} is used as the entry address.
|
|
If there is no symbol called @code{start}, then the entry address
|
|
is set to the first address in the first output section
|
|
(usually the @samp{text} section).
|
|
|
|
@item -f @var{fill}
|
|
Sets the default fill pattern for ``holes'' in the output file to
|
|
the lowest two bytes of the expression specified.
|
|
|
|
@item -i
|
|
Produce an incremental link (same as option @code{-r}).
|
|
|
|
@item -l @var{arch}
|
|
Add an archive file @var{arch} to the list of files to link. This
|
|
option may be used any number of times. @code{ld} will search its
|
|
path-list for occurrences of @code{lib@var{arch}.a} for every @var{arch}
|
|
specified.
|
|
|
|
@c This also has a side effect of using the "c++ demangler" if we happen
|
|
@c to specify -llibg++. Document? pesch@@cygnus.com, 24jan91
|
|
|
|
@item -L @var{searchdir}
|
|
This command adds path @var{searchdir} to the
|
|
list of paths that @code{gld} will search for archive libraries. You
|
|
may use this option any number of times.
|
|
|
|
@c Should we make any attempt to list the standard paths searched
|
|
@c without listing? When hacking on a new system I often want to know
|
|
@c this, but this may not be the place... it's not constant across
|
|
@c systems, of course, which is what makes it interesting.
|
|
@c pesch@@cygnus.com, 24jan91.
|
|
|
|
@item -M
|
|
@itemx -m
|
|
Print (to the standard output file) a link map---diagnostic information
|
|
about where symbols are mapped by @code{ld}, and information on global
|
|
common storage allocation.
|
|
|
|
@item -N
|
|
specifies read and writable @code{text} and @code{data} sections. If
|
|
the output format supports Unix style magic numbers, then OMAGIC is set.
|
|
|
|
@item -n
|
|
sets the text segment to be read only, and @code{NMAGIC} is written
|
|
if possible.
|
|
|
|
@item -o @var{output}
|
|
@var{output} is a name for the program produced by @code{ld}; if this
|
|
option is not specified, the name @samp{a.out} is used by default.
|
|
|
|
@item -r
|
|
Generates relocatable output---i.e., generate an output file that can in
|
|
turn serve as input to @code{gld}. As a side effect, this option also
|
|
sets the output file's magic number to @code{OMAGIC}; see @samp{-N}. If this
|
|
option is not specified, an absolute file is produced.
|
|
|
|
@item -S
|
|
Omits debugger symbol information (but not all symbols) from the output file.
|
|
|
|
@item -s
|
|
Omits all symbol information from the output file.
|
|
|
|
@item -T @var{textorg}
|
|
@itemx -Ttext @var{textorg}
|
|
Use @var{textorg} as the starting address for the @code{text} segment of the
|
|
output file. Both forms of this option are equivalent. The option
|
|
argument must be a hexadecimal integer.
|
|
|
|
@item -Tdata @var{dataorg}
|
|
Use @var{dataorg} as the starting address for the @code{data} segment of
|
|
the output file. The option argument must be a hexadecimal integer.
|
|
|
|
@item -t
|
|
Prints names of input files as @code{ld} processes them.
|
|
|
|
@item -u @var{sym}
|
|
Forces @var{sym} to be entered in the output file as an undefined symbol.
|
|
This may, for example, trigger linking of additional modules from
|
|
standard libraries. @code{-u} may be repeated with different option
|
|
arguments to enter additional undefined symbols. This option is equivalent
|
|
to the @code{EXTERN} linker command.
|
|
|
|
@item -X
|
|
If @code{-s} or @code{-S} is also specified, delete only local symbols
|
|
beginning with @samp{L}.
|
|
|
|
@item -z
|
|
@code{-z} sets @code{ZMAGIC}, the default: the @code{text} segment is
|
|
read-only, demand pageable, and shared.
|
|
|
|
Specifying a relocatable output file (@code{-r}) will also set the magic
|
|
number to @code{OMAGIC}.
|
|
|
|
See description of @samp{-N}.
|
|
|
|
|
|
@end table
|
|
@chapter Command Language
|
|
|
|
|
|
The command language allows explicit control over the linkage process, allowing
|
|
specification of:
|
|
@table @bullet
|
|
@item input files
|
|
@item file formats
|
|
@item output file format
|
|
@item addresses of sections
|
|
@item placement of common blocks
|
|
@item and more
|
|
@end table
|
|
|
|
A command file may be supplied to the linker, either explicitly through the
|
|
@code{-c} option, or implicitly as an ordinary file. If the linker opens
|
|
a file which does not have a reasonable object or archive format, it tries
|
|
to read the file as if it were a command file.
|
|
@section Structure
|
|
To be added
|
|
|
|
@section Expressions
|
|
The syntax for expressions in the command language is identical to that of
|
|
C expressions, with the following features:
|
|
@table @bullet
|
|
@item All expressions evaluated as integers and
|
|
are of ``long'' or ``unsigned long'' type.
|
|
@item All constants are integers.
|
|
@item All of the C arithmetic operators are provided.
|
|
@item Global variables may be referenced, defined and created.
|
|
@item Build in functions may be called.
|
|
@end table
|
|
|
|
@section Expressions
|
|
|
|
The linker has a practice of ``lazy evaluation'' for expressions; it only
|
|
calculates an expression when absolutely necessary. For instance,
|
|
when the linker reads in the command file it has to know the values
|
|
of the start address and the length of the memory regions for linkage to continue, so these
|
|
values are worked out, but other values (such as symbol values) are not
|
|
known or needed until after storage allocation.
|
|
They are evaluated later, when the other
|
|
information, such as the sizes of output sections are available for use in
|
|
the symbol assignment expression.
|
|
|
|
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 relocateable expression type is one in which the value
|
|
is expressed as a fixed offset from the base of a section.
|
|
|
|
The type of the expression is controlled by its position in the script
|
|
file. A symbol assigned within a @code{SECTION} specification 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 @code{SECTION} specification 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 @code{SECTION} specification by using the absolute assignment
|
|
function @code{ABSOLUTE} For example, to create an absolute symbol
|
|
whose address is the last byte of the output section @code{.data}:
|
|
@example
|
|
.data :
|
|
@{
|
|
*(.data)
|
|
_edata = ABSOLUTE(.) ;
|
|
@}
|
|
@end example
|
|
|
|
Unless quoted, symbol names start with a letter, underscore, point or
|
|
minus sign and may include any letters, underscores, digits, points,
|
|
and minus signs. Unquoted symbol names must not conflict with any
|
|
keywords. To specify a symbol which contains odd characters or has
|
|
the same name as a keyword surround it in double quotes:
|
|
@example
|
|
``SECTION'' = 9;
|
|
``with a space'' = ``also with a space'' + 10;
|
|
@end example
|
|
|
|
@subsection Integers
|
|
An octal integer is @samp{0} followed by zero or more of the octal
|
|
digits (@samp{01234567}).
|
|
|
|
A decimal integer starts with a non-zero digit followed by zero or
|
|
more digits (@samp{0123456789}).
|
|
|
|
A hexadecimal integer is @samp{0x} or @samp{0X} followed by one or
|
|
more hexadecimal digits chosen from @samp{0123456789abcdefABCDEF}.
|
|
|
|
Integers have the usual values. To denote a negative integer, use
|
|
the unary operator @samp{-} discussed under expressions.
|
|
|
|
Additionally the suffixes @code{K} and @code{M} may be used to multiply the
|
|
previous constant by 1024 or
|
|
@tex
|
|
$1024^2$
|
|
@end tex
|
|
respectively.
|
|
|
|
@example
|
|
_as_decimal = 57005;
|
|
_as_hex = 0xdead;
|
|
_as_octal = 0157255;
|
|
|
|
_4k_1 = 4K;
|
|
_4k_2 = 4096;
|
|
_4k_3 = 0x1000;
|
|
@end example
|
|
@subsection Operators
|
|
The linker provides the standard C set of arithmetic operators, with
|
|
the standard bindings and precedence levels:
|
|
@example
|
|
|
|
@end example
|
|
@tex
|
|
|
|
\vbox{\offinterlineskip
|
|
\hrule
|
|
\halign
|
|
{\vrule#&\hfil#\hfil&\vrule#&\hfil#\hfil&\vrule#&\hfil#\hfil&\vrule#\cr
|
|
height2pt&&&&&\cr
|
|
&Level&& associativity &&Operators&\cr
|
|
height2pt&&&&&\cr
|
|
\noalign{\hrule}
|
|
height2pt&&&&&\cr
|
|
&highest&&&&&&\cr
|
|
&1&&left&&$ ! - ~$&\cr
|
|
height2pt&&&&&\cr
|
|
&2&&left&&* / \%&\cr
|
|
height2pt&&&&&\cr
|
|
&3&&left&&+ -&\cr
|
|
height2pt&&&&&\cr
|
|
&4&&left&&$>> <<$&\cr
|
|
height2pt&&&&&\cr
|
|
&5&&left&&$== != > < <= >=$&\cr
|
|
height2pt&&&&&\cr
|
|
&6&&left&&\&&\cr
|
|
height2pt&&&&&\cr
|
|
&7&&left&&|&\cr
|
|
height2pt&&&&&\cr
|
|
&8&&left&&{\&\&}&\cr
|
|
height2pt&&&&&\cr
|
|
&9&&left&&||&\cr
|
|
height2pt&&&&&\cr
|
|
&10&&right&&? :&\cr
|
|
height2pt&&&&&\cr
|
|
&11&&right&&$${\&= += -= *= /=}&\cr
|
|
&lowest&&&&&&\cr
|
|
height2pt&&&&&\cr}
|
|
\hrule}
|
|
@end tex
|
|
|
|
@section Built in Functions
|
|
The command language provides built in functions for use in
|
|
expressions in linkage scripts.
|
|
@table @bullet
|
|
@item @code{ALIGN(@var{exp})}
|
|
returns the result of the current location counter (@code{dot})
|
|
aligned to the next @var{exp} boundary, where @var{exp} is a power of
|
|
two. This is equivalent to @code{(. + @var{exp} -1) & ~(@var{exp}-1)}.
|
|
As an example, to align the output @code{.data} section to the
|
|
next 0x2000 byte boundary after the preceding section and to set a
|
|
variable within the section to the next 0x8000 boundary after the
|
|
input sections:
|
|
@example
|
|
.data ALIGN(0x2000) :@{
|
|
*(.data)
|
|
variable = ALIGN(0x8000);
|
|
@}
|
|
@end example
|
|
|
|
@item @code{ADDR(@var{section name})}
|
|
returns the absolute address of the named section if the section has
|
|
already been bound. In the following examples the @code{symbol_1} and
|
|
@code{symbol_2} are assigned identical values:
|
|
@example
|
|
.output1:
|
|
@{
|
|
start_of_output_1 $= .;
|
|
...
|
|
@}
|
|
.output:
|
|
@{
|
|
symbol_1 = ADDR(.output1);
|
|
symbol_2 = start_of_output_1;
|
|
@}
|
|
@end example
|
|
|
|
@item @code{SIZEOF(@var{section name})}
|
|
returns the size in bytes of the named section, if the section has
|
|
been allocated. In the following example the @code{symbol_1} and
|
|
@code{symbol_2} are assigned identical values:
|
|
@example
|
|
.output @{
|
|
.start = . ;
|
|
...
|
|
.end = .;
|
|
@}
|
|
symbol_1 = .end - .start;
|
|
symbol_2 = SIZEOF(.output);
|
|
@end example
|
|
|
|
@item @code{DEFINED(@var{symbol name})}
|
|
Returns 1 if the symbol is in the linker global symbol table and is
|
|
defined, otherwise it returns 0. This example shows the setting of a
|
|
global symbol @code{begin} to the first location in the @code{.text}
|
|
section, only if there is no other symbol
|
|
called @code{begin} already:
|
|
@example
|
|
.text: @{
|
|
begin = DEFINED(begin) ? begin : . ;
|
|
...
|
|
@}
|
|
@end example
|
|
@end table
|
|
@page
|
|
@section MEMORY Directive
|
|
The linker's default configuration is for all memory to be
|
|
allocatable. This state may be overridden by using the @code{MEMORY}
|
|
directive. The @code{MEMORY} directive describes the location and
|
|
size of blocks of memory in the target. Careful use can describe
|
|
memory regions which may or may not be used by the linker. 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. The syntax is:
|
|
|
|
@example
|
|
MEMORY
|
|
@{
|
|
@tex
|
|
$\bigl\lbrace {\it name_1} ({\it attr_1}):$ ORIGIN = ${\it origin_1},$ LENGTH $= {\it len_1} \bigr\rbrace $
|
|
@end tex
|
|
|
|
@}
|
|
@end example
|
|
@table @code
|
|
@item @var{name}
|
|
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, filenames or section
|
|
names.
|
|
@item @var{attr}
|
|
is an optional list of attributes, parsed for compatibility with the
|
|
AT+T linker
|
|
but ignored by the both the AT+T and the gnu linker.
|
|
@item @var{origin}
|
|
is the start address of the region in physical memory expressed as
|
|
standard linker expression which must evaluate to a constant before
|
|
memory allocation is performed. The keyword @code{ORIGIN} may be
|
|
abbreviated to @code{org} or @code{o}.
|
|
@item @var{len}
|
|
is the size in bytes of the region as a standard linker expression.
|
|
The keyword @code{LENGTH} may be abbreviated to @code{len} or @code{l}
|
|
@end table
|
|
|
|
For example, to specify that memory has two regions available for
|
|
allocation; one starting at 0 for 256k, and the other starting at
|
|
0x40000000 for four megabytes:
|
|
|
|
@example
|
|
MEMORY
|
|
@{
|
|
rom : ORIGIN= 0, LENGTH = 256K
|
|
ram : ORIGIN= 0x40000000, LENGTH = 4M
|
|
@}
|
|
|
|
@end example
|
|
|
|
If the combined output sections directed to a region are too big for
|
|
the region the linker will emit an error message.
|
|
@page
|
|
@section SECTIONS Directive
|
|
The @code{SECTIONS} directive
|
|
controls exactly where input sections are placed into output sections, their
|
|
order and to which output sections they are allocated.
|
|
|
|
When no @code{SECTIONS} directives are specified, the default action
|
|
of the linker is to place each input section into an identically named
|
|
output section in the order that the sections appear in the first
|
|
file, and then the order of the files.
|
|
|
|
The syntax of the @code{SECTIONS} directive is:
|
|
|
|
@example
|
|
SECTIONS
|
|
@{
|
|
@tex
|
|
$\bigl\lbrace {\it name_n}\bigl[options\bigr]\colon$ $\bigl\lbrace {\it statements_n} \bigr\rbrace \bigl[ = {\it fill expression } \bigr] \bigl[ > mem spec \bigr] \bigr\rbrace $
|
|
@end tex
|
|
@}
|
|
@end example
|
|
|
|
@table @code
|
|
@item @var{name}
|
|
controls the name of the output section. In formats which only support
|
|
a limited number of sections, such as @code{a.out}, the name must be
|
|
one of the names supported by the format (in the case of a.out,
|
|
@code{.text}, @code{.data} or @code{.bss}). If the output format
|
|
supports any number of sections, but with numbers and not names (in
|
|
the case of IEEE), the name should be supplied as a quoted numeric
|
|
string. A section name may consist of any sequence characters, but
|
|
any name which does not conform to the standard @code{gld} symbol name
|
|
syntax must be quoted. To copy sections 1 through 4 from a Oasys file
|
|
into the @code{.text} section of an @code{a.out} file, and sections 13
|
|
and 14 into the @code{data} section:
|
|
@example
|
|
|
|
SECTION @{
|
|
.text :@{
|
|
*(``1'' ``2'' ``3'' ``4'')
|
|
@}
|
|
|
|
.data :@{
|
|
*(``13'' ``14'')
|
|
@}
|
|
@}
|
|
@end example
|
|
|
|
@item @var{fill expression}
|
|
If present this
|
|
expression sets the fill value. 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.
|
|
@page
|
|
@item @var{options}
|
|
the @var{options} parameter is a list of optional arguments specifying
|
|
attributes of the output section, they may be taken from the following
|
|
list:
|
|
@table @bullet{}
|
|
@item @var{addr expression}
|
|
forces the output section to be loaded at a specified address. The
|
|
address is specified as a standard linker expression. The following
|
|
example generates section @var{output} at location
|
|
@code{0x40000000}:
|
|
@example
|
|
SECTIONS @{
|
|
output 0x40000000: @{
|
|
...
|
|
@}
|
|
@}
|
|
@end example
|
|
Since the built in function @code{ALIGN} references the location
|
|
counter implicitly, a section may be located on a certain boundary by
|
|
using the @code{ALIGN} function in the expression. For example, to
|
|
locate the @code{.data} section on the next 8k boundary after the end
|
|
of the @code{.text} section:
|
|
@example
|
|
SECTIONS @{
|
|
.text @{
|
|
...
|
|
@}
|
|
.data ALIGN(4K) @{
|
|
...
|
|
@}
|
|
@}
|
|
@end example
|
|
@end table
|
|
@item @var{statements}
|
|
is a list of file names, input sections and assignments. These statements control what is placed into the
|
|
output section.
|
|
The syntax of a single @var{statement} is one of:
|
|
@table @bullet
|
|
|
|
@item @var{symbol} [ $= | += | -= | *= | /= ] @var{ expression} @code{;}
|
|
|
|
Global symbols may be created and have their values (addresses)
|
|
altered using the assignment statement. The linker tries to put off
|
|
the evaluation of an assignment until all the terms in the source
|
|
expression are known; 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 @code{dot}, @samp{.} must be
|
|
evaluated during allocation. If the result of an expression is
|
|
required, but the value is not available, then an error results: eg
|
|
@example
|
|
SECTIONS @{
|
|
text 9+this_isnt_constant:
|
|
@{
|
|
@}
|
|
@}
|
|
testscript:21: Non constant expression for initial address
|
|
@end example
|
|
|
|
@item @code{CREATE_OBJECT_SYMBOLS}
|
|
causes the linker to create a symbol for each input file and place it
|
|
into the specified section set with the value of the first byte of
|
|
data written from the input file. For instance, with @code{a.out}
|
|
files it is conventional to have a symbol for each input file.
|
|
@example
|
|
SECTIONS @{
|
|
.text 0x2020 :
|
|
@{
|
|
CREATE_OBJECT_SYMBOLS
|
|
*(.text)
|
|
_etext = ALIGN(0x2000);
|
|
@}
|
|
@}
|
|
@end example
|
|
Supplied with four object files, @code{a.o}, @code{b.o}, @code{c.o},
|
|
and @code{d.o} a run of
|
|
@code{gld} could create a map:
|
|
@example
|
|
From functions like :
|
|
a.c:
|
|
afunction() { }
|
|
int adata=1;
|
|
int abss;
|
|
|
|
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
|
|
|
|
@end example
|
|
|
|
@item @var{filename} @code{(} @var{section name list} @code{)}
|
|
This command allocates all the named sections from the input object
|
|
file supplied into the output section at the current point. Sections
|
|
are written in the order they appear in the list so:
|
|
@example
|
|
SECTIONS @{
|
|
.text 0x2020 :
|
|
@{
|
|
a.o(.data)
|
|
b.o(.data)
|
|
*(.text)
|
|
@}
|
|
.data :
|
|
@{
|
|
*(.data)
|
|
@}
|
|
.bss :
|
|
@{
|
|
*(.bss)
|
|
COMMON
|
|
@}
|
|
@}
|
|
@end example
|
|
will produce a map:
|
|
@example
|
|
|
|
insert here
|
|
@end example
|
|
@item @code{* (} @var{section name list} @code{)}
|
|
This command causes all sections from all input files which have not
|
|
yet been assigned output sections to be assigned the current output
|
|
section.
|
|
|
|
@item @var{filename} @code{[COMMON]}
|
|
This allocates all the common symbols from the specified file and places
|
|
them into the current output section.
|
|
|
|
@item @code{* [COMMON]}
|
|
This allocates all the common symbols from the files which have not
|
|
yet had their common symbols allocated and places them into the current
|
|
output section.
|
|
|
|
@item @var{filename}
|
|
A filename alone within a @code{SECTIONS} statement will cause all the
|
|
input sections from the file to be placed into the current output
|
|
section at the current location. If the file name has been mentioned
|
|
before with a section name list then only those
|
|
sections which have not yet been allocated are noted.
|
|
|
|
The following example reads all of the sections from file all.o and
|
|
places them at the start of output section @code{outputa} which starts
|
|
at location @code{0x10000}. All of the data from section @code{.input1} from
|
|
file foo.o is placed next into the same output section. All of
|
|
section @code{.input2} is read from foo.o and placed into output
|
|
section @code{outputb}. Next all of section @code{.input1} is read
|
|
from foo1.o. All of the remaining @code{.input1} and @code{.input2}
|
|
sections from any files are written to output section @code{output3}.
|
|
|
|
@example
|
|
SECTIONS
|
|
@{
|
|
outputa 0x10000 :
|
|
@{
|
|
all.o
|
|
foo.o (.input1)
|
|
@}
|
|
outputb :
|
|
@{
|
|
foo.o (.input2)
|
|
foo1.o (.input1)
|
|
@}
|
|
outputc :
|
|
@{
|
|
*(.input1)
|
|
*(.input2)
|
|
@}
|
|
@}
|
|
|
|
@end example
|
|
@end table
|
|
@end table
|
|
@section Using the Location Counter
|
|
The special linker variable @code{dot}, @samp{.} always contains the
|
|
current output location counter. Since the @code{dot} always refers to
|
|
a location in an output section, it must always appear in an
|
|
expression within a @code{SECTIONS} directive. The @code{dot} symbol
|
|
may appear anywhere that an ordinary symbol may appear in an
|
|
expression, but its assignments have a side effect. Assigning a value
|
|
to the @code{dot} symbol will cause the location counter to be moved.
|
|
This may be used to create holes in the output section. The location
|
|
counter may never be moved backwards.
|
|
@example
|
|
SECTIONS
|
|
@{
|
|
output :
|
|
@{
|
|
file1(.text)
|
|
. = . + 1000;
|
|
file2(.text)
|
|
. += 1000;
|
|
file3(.text)
|
|
. -= 32;
|
|
file4(.text)
|
|
@} = 0x1234;
|
|
@}
|
|
@end example
|
|
In the previous example, @code{file1} is located at the beginning of
|
|
the output section, then there is a 1000 byte gap, filled with 0x1234.
|
|
Then @code{file2} appears, also with a 1000 byte gap following before
|
|
@code{file3} is loaded. Then the first 32 bytes of @code{file4} are
|
|
placed over the last 32 bytes of @code{file3}.
|
|
@section Command Language Syntax
|
|
@section The Entry Point
|
|
The linker chooses the first executable instruction in an output file from a list
|
|
of possibilities, in order:
|
|
@itemize @bullet
|
|
@item
|
|
The value of the symbol provided to the command line with the @code{-e} option, when
|
|
present.
|
|
@item
|
|
The value of the symbol provided in the @code{ENTRY} directive,
|
|
if present.
|
|
@item
|
|
The value of the symbol @code{start}, if present.
|
|
@item
|
|
The value of the symbol @code{_main}, if present.
|
|
@item
|
|
The address of the first byte of the @code{.text} section, if present.
|
|
@item
|
|
The value 0.
|
|
@end itemize
|
|
If the symbol @code{start} is not defined within the set of input
|
|
files to a link, it may be generated by a simple assignment
|
|
expression. eg.
|
|
@example
|
|
start = 0x2020;
|
|
@end example
|
|
@section Section Attributes
|
|
@section Allocation of Sections into Memory
|
|
@section Defining Symbols
|
|
@chapter Examples of operation
|
|
The simplest case is linking standard Unix object files on a standard
|
|
Unix system supported by the linker. To link a file hello.o:
|
|
@example
|
|
$ gld -o output /lib/crt0.o hello.o -lc
|
|
@end example
|
|
This tells gld to produce a file called @code{output} after linking
|
|
the file @code{/lib/crt0.o} with @code{hello.o} and the library
|
|
@code{libc.a} which will come from the standard search directories.
|
|
@chapter Partial Linking
|
|
Specifying the @code{-r} on the command line causes @code{gld} to
|
|
perform a partial link.
|
|
|
|
|
|
@chapter BFD
|
|
|
|
The linker accesses object and archive files using the @code{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 @code{bfd} back end and adding it to the library.
|
|
|
|
Formats currently supported:
|
|
@itemize @bullet
|
|
@item
|
|
Sun3 68k a.out
|
|
@item
|
|
IEEE-695 68k Object Module Format
|
|
@item
|
|
Oasys 68k Binary Relocatable Object File Format
|
|
@item
|
|
Sun4 sparc a.out
|
|
@item
|
|
88k bcs coff
|
|
@item
|
|
i960 coff little endian
|
|
@item
|
|
i960 coff big endian
|
|
@item
|
|
i960 b.out little endian
|
|
@item
|
|
i960 b.out big endian
|
|
@end itemize
|
|
|
|
As with most implementations, @code{bfd} is a compromise between
|
|
several conflicting requirements. The major factor influencing
|
|
@code{bfd} design was efficiency, any time used converting between
|
|
formats is time which would not have been spent had @code{bfd} not
|
|
been involved. This is partly offset by abstraction payback; since
|
|
@code{bfd} simplifies applications and back ends, more time and care
|
|
may be spent optimizing algorithms for a greater speed.
|
|
|
|
One minor artifact of the @code{bfd} solution which the
|
|
user should be aware of is information lossage.
|
|
There are two places where useful information can be lost using the
|
|
@code{bfd} mechanism; during conversion and during output.
|
|
|
|
@section How it works
|
|
When an object file is opened, @code{bfd}
|
|
tries to automatically determine the format of the input object file, a
|
|
descriptor is built in memory with pointers to routines to access
|
|
elements of the object file's data structures.
|
|
|
|
As different information from the the object files is required
|
|
@code{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 @code{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 the memory pointer to the relevant
|
|
@code{bfd} back end routine which reads and converts the table into
|
|
the canonical form. Linker then operates upon the common form. When
|
|
the link is finished and the linker writes the symbol table of the
|
|
output file, another @code{bfd} back end routine is called which takes
|
|
the newly created symbol table and converts it into the output format.
|
|
|
|
@section Information Leaks
|
|
@table @bullet{}
|
|
@item Information lost during output.
|
|
The output formats supported by @code{bfd} do not provide identical
|
|
facilities, and information which may be described in one form
|
|
has no where to go in another format. One example of this would be
|
|
alignment information in @code{b.out}. There is no where in an @code{a.out}
|
|
format file to store alignment information on the contained data, so when
|
|
a file is linked from @code{b.out} and an @code{a.out} image is produced,
|
|
alignment information is lost. (Note that in this case the linker has the
|
|
alignment information internally, so the link is performed correctly).
|
|
|
|
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
|
|
(eg @code{a.out}) or has sections without names (eg the Oasys format)
|
|
the link cannot be done simply. It is possible to circumvent this
|
|
problem by describing the desired input section to output section
|
|
mapping with the command language.
|
|
|
|
@item Information lost during canonicalization.
|
|
The @code{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 @code{bfd} back ends
|
|
cannot maintain all the data richness through the transformation
|
|
between external to internal and back to external formats.
|
|
|
|
This limitation is only a problem when using the linker to read one
|
|
format and write another. Each @code{bfd} back end is responsible for
|
|
maintaining as much data as possible, and the internal @code{bfd}
|
|
canonical form has structures which are opaque to the @code{bfd} core,
|
|
and exported only to the back ends. When a file is read in one format,
|
|
the canonical form is generated for @code{bfd} and the linker. At the
|
|
same time, the back end saves away any information which may otherwise
|
|
be lost. If the data is then written back to the same back end, the
|
|
back end routine will be able to use the canonical form provided by
|
|
the @code{bfd} core as well as the information it prepared earlier.
|
|
Since there is a great deal of commonality between back ends, this
|
|
mechanism is very useful. There is no information lost when linking
|
|
big endian COFF to little endian COFF, or from a.out to b.out. When a
|
|
mixture of formats are linked, the information is only lost from the
|
|
files with a different format to the destination.
|
|
@end table
|
|
@section Mechanism
|
|
The smallest amount of information is preserved when there
|
|
is a small union between the information provided by the source
|
|
format, that stored by the canonical format and the information needed
|
|
by the destination format. A brief description of the canonical form
|
|
will help the user appreciate what is possible to be maintained
|
|
between conversions.
|
|
|
|
@table @bullet
|
|
@item file level Information on target machine
|
|
architecture, particular implementation and format type are stored on
|
|
a per file basis. Other information includes a demand pageable bit and
|
|
a write protected bit. Note that information like Unix magic numbers
|
|
is not stored here, only the magic numbers meaning, so a ZMAGIC file
|
|
would have both the demand pageable bit and the write protected text
|
|
bit set.
|
|
|
|
The byte order of the target is stored on a per file basis, so that
|
|
both big and little endian object files may be linked together at the
|
|
same time.
|
|
@item section level
|
|
Each section in the input file contains the name of the section, the
|
|
original address in the object file, various flags, size and alignment
|
|
information and pointers into other @code{bfd} data structures.
|
|
@item symbol level
|
|
Each symbol contains a pointer to the object file which originally
|
|
defined it, its name, value and various flags bits. When a symbol
|
|
table is read in all symbols are relocated to make them relative to
|
|
the base of the section they were defined in, so each symbol points to
|
|
the containing section. Each symbol also has a varying amount of
|
|
hidden data to contain private data for the back end. Since the symbol
|
|
points to the original file, the symbol private data format is
|
|
accessible. Operations may be done to a list of symbols of wildly
|
|
different formats without problems.
|
|
|
|
Normal global and simple local symbols are maintained on output, so an
|
|
output file, no matter the format will retain symbols pointing to
|
|
functions, globals, statics and commons. Some symbol information is
|
|
not worth retaining; in @code{a.out} type information is stored in the
|
|
symbol table as long symbol names. This information would be useless
|
|
to most coff debuggers and may be thrown away with appropriate command
|
|
line switches. (Note that gdb does support stabs in coff).
|
|
|
|
There is one word of type information within the symbol, so if the
|
|
format supports symbol type information within symbols - (eg COFF,
|
|
IEEE, Oasys) and the type is simple enough to fit within one word
|
|
(nearly everything but aggregates) the information will be preserved.
|
|
|
|
@item relocation level
|
|
Each canonical 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 effectively by message passing through the relocation type
|
|
descriptor and symbol pointer. It allows relocations to be performed
|
|
on output data using a relocation method 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 COFF file, even though 68k COFF
|
|
has no such relocation type.
|
|
|
|
@item line numbers
|
|
Line numbers 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 divination of the address of
|
|
the function who's line number is being described. The rest of the
|
|
list is tuples offsets into the section and line indexes. Any format
|
|
which can simply derive this information can pass it without lossage
|
|
between formats (COFF, IEEE and Oasys).
|
|
@end table
|
|
|
|
|
|
@bye
|
|
|
|
|