From: Subject: Using LD, the GNU linker Date: Tue, 15 Jul 2003 12:05:59 +0200 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.cslab.vt.edu/manuals/ld-2.9.1/html_mono/ld.html X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Using LD, the GNU linker

Using ld

The GNU linker

ld version 2

January 1994

Steve Chamberlain
Cygnus Support

Table of Contents

Copyright (C) 1991, 92, 93, 94, 95, 96, 97, 1998 Free Software = Foundation,=20 Inc.

Permission is granted to make and distribute verbatim copies of this = manual=20 provided the copyright notice and this permission notice are preserved = on all=20 copies.

Permission is granted to copy and distribute modified versions of = this manual=20 under the conditions for verbatim copying, provided also that the entire = resulting derived work is distributed under the terms of a permission = notice=20 identical to this one.

Permission is granted to copy and distribute translations of this = manual into=20 another language, under the above conditions for modified versions.

Overview

ld combines a = number of object=20 and archive files, relocates their data and ties up symbol references. = Usually=20 the last step in compiling a program is to run ld.

ld accepts Linker Command Language files written in a = superset=20 of AT&T's Link Editor Command Language syntax, to provide explicit = and total=20 control over the linking process.

This version of ld uses the general purpose BFD = libraries to=20 operate on object files. This allows ld to read, combine, = and write=20 object files in many different formats--for example, COFF or = a.out.=20 Different formats may be linked together to produce any available kind = of object=20 file. See section BFD,=20 for more information.

Aside from its flexibility, the GNU linker is more helpful than other = linkers=20 in providing diagnostic information. Many linkers abandon execution = immediately=20 upon encountering an error; whenever possible, ld continues = executing, allowing you to identify other errors (or, in some cases, to = get an=20 output file in spite of the error).

Invocation

The GNU linker ld is meant to cover a broad range of = situations,=20 and to be as compatible as possible with other linkers. As a result, you = have=20 many choices to control its behavior.

Command Line Options

The linker supports a plethora = of=20 command-line options, but in actual practice few of them are used in any = particular context. For instance, a frequent use of=20 ld is to link standard Unix object files on a standard, = supported=20 Unix system. On such a system, to link a file hello.o: = 

ld -o output /lib/crt0.o hello.o -lc

This tells ld to produce a file called output = as the=20 result of linking the file /lib/crt0.o with = hello.o=20 and the library libc.a, which will come from the standard = search=20 directories. (See the discussion of the `-l' option below.) =

The command-line options to ld may be specified in any = order,=20 and may be repeated at will. Repeating most options with a different = argument=20 will either have no further effect, or override prior occurrences (those = further=20 to the left on the command line) of that option. Options which may be=20 meaningfully specified more than once are noted in the descriptions = below.

Non-option arguments are objects files which are = to be=20 linked together. They may follow, precede, or be mixed in with = command-line=20 options, except that an object file argument may not be placed between = an option=20 and its argument.

Usually the linker is invoked with at least one object file, but you = can=20 specify other forms of binary input files using `-l',=20 `-R', and the script command language. If no = binary input=20 files at all are specified, the linker does not produce any output, and = issues=20 the message `No input files'.

If the linker can not recognize the format of an object file, it will = assume=20 that it is a linker script. A script specified in this way augments the = main=20 linker script used for the link (either the default linker script or the = one=20 specified by using `-T'). This feature permits the linker = to link=20 against a file which appears to be an object or an archive, but actually = merely=20 defines some symbol values, or uses INPUT or = GROUP to=20 load other objects. Note that specifying a script in this way should = only be=20 used to augment the main linker script; if you want to use some command = that=20 logically can only appear once, such as the SECTIONS or=20 MEMORY command, you must replace the default linker script = using=20 the `-T' option. See section = Command=20 Language.

For options whose names are a single letter, option arguments must = either=20 follow the option letter without intervening whitespace, or be given as = separate=20 arguments immediately following the option that requires them.

For options whose names are multiple letters, either one dash or two = can=20 precede the option name; for example, `--oformat' and=20 `--oformat' are equivalent. Arguments to multiple-letter = options=20 must either be separated from the option name by an equals sign, or be = given as=20 separate arguments immediately following the option that requires them. = For=20 example, `--oformat srec' and = `--oformat=3Dsrec' are=20 equivalent. Unique abbreviations of the names of multiple-letter options = are=20 accepted.

-akeyword=20
This option is supported for HP/UX = compatibility. The=20 keyword argument must be one of the strings = `archive',=20 `shared', or `default'. = `-aarchive' is=20 functionally equivalent to `-Bstatic', and the other two = keywords=20 are functionally equivalent to `-Bdynamic'. This option = may be=20 used any number of times.
-Aarchitecture=20
--architecture=3Darchitecture=20
In the current release of ld, this option is useful = only for=20 the Intel 960 family of architectures. In that ld = configuration,=20 the architecture argument identifies the particular = architecture in=20 the 960 family, enabling some safeguards and modifying the = archive-library=20 search path. See section ld=20 and the Intel 960 family, for details. Future releases of = ld=20 may support similar functionality for other architecture families.
-b input-format=20
--format=3Dinput-format=20
ld may be configured to support more than one kind of = object=20 file. If your ld is configured this way, you can use the=20 `-b' option to specify the binary format for input object = files=20 that follow this option on the command line. Even when ld = is=20 configured to support alternative object formats, you don't usually = need to=20 specify this, as ld should be configured to expect as a = default=20 input format the most usual format on each machine. = input-format is=20 a text string, the name of a particular format supported by the BFD = libraries.=20 (You can list the available binary formats with `objdump = -i'.)=20 See section BFD.=20 You may want to use this option if you are linking files with an = unusual=20 binary format. You can also use `-b' to switch formats = explicitly=20 (when linking object files of different formats), by including = `-b=20 input-format' before each group of object files in a = particular format. The default format is taken from the environment = variable=20 GNUTARGET. See section = Environment=20 Variables. You can also define the input format from a script, = using the=20 command TARGET; see section Option=20 Commands.
-c MRI-commandfile=20
--mri-script=3DMRI-commandfile=20
For compatibility with linkers produced by MRI, ld = accepts=20 script files written in an alternate, restricted command language, = described=20 in section MRI=20 Compatible Script Files. Introduce MRI script files with the = option=20 `-c'; use the `-T' option to run linker = scripts=20 written in the general-purpose ld scripting language. If=20 MRI-cmdfile does not exist, ld looks for it in = the=20 directories specified by any `-L' options.
-d=20
-dc=20
-dp=20
These three options are equivalent; multiple forms are supported = for=20 compatibility with other linkers. They assign space to common symbols = even if=20 a relocatable output file is specified (with `-r'). The = script=20 command FORCE_COMMON_ALLOCATION has the same effect. See = section=20 Option=20 Commands.
-e entry=20
--entry=3Dentry=20
Use entry as the explicit symbol for beginning = execution of=20 your program, rather than the default entry point. See section The=20 Entry Point, for a discussion of defaults and other ways of = specifying the=20 entry point.
-E=20
--export-dynamic=20
When creating a dynamically linked executable, add all symbols to = the=20 dynamic symbol table. The dynamic symbol table is the set of symbols = which are=20 visible from dynamic objects at run time. If you do not use this = option, the=20 dynamic symbol table will normally contain only those symbols which = are=20 referenced by some dynamic object mentioned in the link. If you use=20 dlopen to load a dynamic object which needs to refer back = to the=20 symbols defined by the program, rather than some other dynamic object, = then=20 you will probably need to use this option when linking the program = itself.
-f=20
--auxiliary name=20
When creating an ELF shared object, set the internal DT_AUXILIARY = field to=20 the specified name. This tells the dynamic linker that the symbol = table of the=20 shared object should be used as an auxiliary filter on the symbol = table of the=20 shared object name. If you later link a program against = this filter=20 object, then, when you run the program, the dynamic linker will see = the=20 DT_AUXILIARY field. If the dynamic linker resolves any symbols from = the filter=20 object, it will first check whether there is a definition in the = shared object=20 name. If there is one, it will be used instead of the = definition in=20 the filter object. The shared object name need not exist. = Thus the=20 shared object name may be used to provide an alternative=20 implementation of certain functions, perhaps for debugging or for = machine=20 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=20 command line.
-F name=20
--filter name=20
When creating an ELF shared object, set the internal DT_FILTER = field to=20 the specified name. This tells the dynamic linker that the symbol = table of the=20 shared object which is being created should be used as a filter on the = symbol=20 table of the shared object name. If you later link a = program=20 against this filter object, then, when you run the program, the = dynamic linker=20 will see the DT_FILTER field. The dynamic linker will resolve symbols=20 according to the symbol table of the filter object as usual, but it = will=20 actually link to the definitions found in the shared object = name.=20 Thus the filter object can be used to select a subset of the symbols = provided=20 by the object name. Some older linkers used the = -F=20 option throughout a compilation toolchain for specifying object-file = format=20 for both input and output object files. The GNU linker uses other = mechanisms=20 for this purpose: the -b, --format,=20 --oformat options, the TARGET command in = linker=20 scripts, and the GNUTARGET environment variable. The GNU = linker=20 will ignore the -F option when not creating an ELF shared = object.=20
--force-exe-suffix=20
Make sure that an output file has a .exe suffix. If a successfully = built=20 fully linked output file does not have a .exe or=20 .dll suffix, this option forces the linker to copy the = output=20 file to one of the same name with a .exe suffix. This = option is=20 useful when using unmodified Unix makefiles on a Microsoft Windows = host, since=20 some versions of Windows won't run an image unless it ends in a=20 .exe suffix.
-g=20
Ignored. Provided for compatibility with other tools.
-Gvalue=20
--gpsize=3Dvalue=20
Set the maximum size of objects to be optimized using the GP = register to=20 size. This is only meaningful for object file formats such = as MIPS=20 ECOFF which supports putting large and small objects into different = sections.=20 This is ignored for other object file formats.
-hname=20
-soname=3Dname=20
When creating an ELF shared object, set the internal DT_SONAME = field to=20 the specified name. When an executable is linked with a shared object = which=20 has a DT_SONAME field, then when the executable is run the dynamic = linker will=20 attempt to load the shared object specified by the DT_SONAME field = rather than=20 the using the file name given to the linker.
-i=20
Perform an incremental link (same as option `-r').
-larchive=20
--library=3Darchive=20
Add archive file archive to the list of files to link. = This=20 option may be used any number of times. ld will search = its=20 path-list for occurrences of libarchive.a for = every=20 archive specified. On systems which support shared = libraries,=20 ld may also search for libraries with extensions other = than=20 .a. Specifically, on ELF and SunOS systems, = ld will=20 search a directory for a library with an extension of .so = before=20 searching for one with an extension of .a. By convention, = a=20 .so extension indicates a shared library. The linker will = search=20 an archive only once, at the location where it is specified on the = command=20 line. If the archive defines a symbol which was undefined in some = object which=20 appeared before the archive on the command line, the linker will = include the=20 appropriate file(s) from the archive. However, an undefined symbol in = an=20 object appearing later on the command line will not cause the linker = to search=20 the archive again. See the -( option for a way to force = the=20 linker to search archives multiple times. You may list the same = archive=20 multiple times on the command line. This type of archive searching is = standard=20 for Unix linkers. However, if you are using ld on AIX, = note that=20 it is different from the behaviour of the AIX linker.
-Lsearchdir=20
--library-path=3Dsearchdir=20
Add path searchdir to the list of paths that = ld=20 will search for archive libraries and ld control scripts. = You may=20 use this option any number of times. The directories are searched in = the order=20 in which they are specified on the command line. Directories specified = on the=20 command line are searched before the default directories. All = -L=20 options apply to all -l options, regardless of the order = in which=20 the options appear. The default set of paths searched (without being = specified=20 with `-L') depends on which emulation mode = ld is=20 using, and in some cases also on how it was configured. See section = Environment=20 Variables. The paths can also be specified in a link script with = the=20 SEARCH_DIR command. Directories specified this way are = searched=20 at the point in which the linker script appears in the command line. =
-memulation=20
Emulate the emulation linker. You can list the = available=20 emulations with the `--verbose' or `-V' = options. If=20 the `-m' option is not used, the emulation is taken from = the=20 LDEMULATION environment variable, if that is defined. = Otherwise,=20 the default emulation depends upon how the linker was configured.
-M=20
--print-map=20
Print a link map to the standard output. A link map provides = information=20 about the link, including the following:=20
  • Where object files and symbols are mapped into memory.=20
  • How common symbols are allocated.=20
  • All archive members included in the link, with a mention of the = symbol=20 which caused the archive member to be brought in.
-n=20
--nmagic=20
Set the text segment to be read only, and mark the output as=20 NMAGIC if possible.
-N=20
--omagic=20
Set the text and data sections to be readable and writable. Also, = do not=20 page-align the data segment. If the output format supports Unix style = magic=20 numbers, mark the output as OMAGIC.
-o output=20
--output=3Doutput=20
Use output as the name for the program produced by=20 ld; if this option is not specified, the name = `a.out' is=20 used by default. The script command OUTPUT can also = specify the=20 output file name.
-r=20
--relocateable=20
Generate relocatable output--i.e., generate an output file that = can in=20 turn serve as input to ld. This is often called = partial=20 linking. As a side effect, in environments that support standard = Unix=20 magic numbers, this option also sets the output file's magic number to = OMAGIC. If this option is not specified, an absolute file = is=20 produced. When linking C++ programs, this option will not = resolve=20 references to constructors; to do that, use `-Ur'. This = option=20 does the same thing as `-i'.
-R filename=20
--just-symbols=3Dfilename=20
Read symbol names and their addresses from filename, = but do not=20 relocate it or include it in the output. This allows your output file = to refer=20 symbolically to absolute locations of memory defined in other = programs. You=20 may use this option more than once. For compatibility with other ELF = linkers,=20 if the -R option is followed by a directory name, rather = than a=20 file name, it is treated as the -rpath option.
-s=20
--strip-all=20
Omit all symbol information from the output file.
-S=20
--strip-debug=20
Omit debugger symbol information (but not all symbols) from the = output=20 file.
-t=20
--trace=20
Print the names of the input files as ld processes = them.
-T commandfile=20
--script=3Dcommandfile=20
Read link commands from the file commandfile. These = commands=20 replace ld's default link script (rather than adding to = it), so=20 commandfile must specify everything necessary to describe = the=20 target format. You must use this option if you want to use a command = which can=20 only appear once in a linker script, such as the SECTIONS = or=20 MEMORY command. See section = Command=20 Language. If commandfile does not exist, = ld looks=20 for it in the directories specified by any preceding `-L' = options. Multiple `-T' options accumulate.
-u symbol=20
--undefined=3Dsymbol=20
Force symbol to be entered in the output file as an = undefined=20 symbol. Doing this may, for example, trigger linking of additional = modules=20 from standard libraries. `-u' may be repeated with = different=20 option arguments to enter additional undefined symbols.
-v=20
--version=20
-V=20
Display the version number for ld. The = -V option=20 also lists the supported emulations.
-x=20
--discard-all=20
Delete all local symbols.
-X=20
--discard-locals=20
Delete all temporary local symbols. For most targets, this is all = local=20 symbols whose names begin with `L'.
-y symbol=20
--trace-symbol=3Dsymbol=20
Print the name of each linked file in which symbol = appears.=20 This option may be given any number of times. On many systems it is = necessary=20 to prepend an underscore. This option is useful when you have an = undefined=20 symbol in your link but don't know where the reference is coming from. =
-Y path=20
Add path to the default library search path. This = option exists=20 for Solaris compatibility.
-z keyword=20
This option is ignored for Solaris compatibility.
-( archives -)=20
--start-group archives --end-group=20
The archives should be a list of archive files. They = may be=20 either explicit file names, or `-l' options. The = specified=20 archives are searched repeatedly until no new undefined references are = created. Normally, an archive is searched only once in the order that = it is=20 specified on the command line. If a symbol in that archive is needed = to=20 resolve an undefined symbol referred to by an object in an archive = that=20 appears later on the command line, the linker would not be able to = resolve=20 that reference. By grouping the archives, they all be searched = repeatedly=20 until all possible references are resolved. Using this option has a=20 significant performance cost. It is best to use it only when there are = unavoidable circular references between two or more archives.
-assert keyword=20
This option is ignored for SunOS compatibility.
-Bdynamic=20
-dy=20
-call_shared=20
Link against dynamic libraries. This is only meaningful on = platforms for=20 which shared libraries are supported. This option is normally the = default on=20 such platforms. The different variants of this option are for = compatibility=20 with various systems. You may use this option multiple times on the = command=20 line: it affects library searching for -l options which = follow=20 it.
-Bstatic=20
-dn=20
-non_shared=20
-static=20
Do not link against shared libraries. This is only meaningful on = platforms=20 for which shared libraries are supported. The different variants of = this=20 option are for compatibility with various systems. You may use this = option=20 multiple times on the command line: it affects library searching for=20 -l options which follow it.
-Bsymbolic=20
When creating a shared library, bind references to global symbols = to the=20 definition within the shared library, if any. Normally, it is possible = for a=20 program linked against a shared library to override the definition = within the=20 shared library. This option is only meaningful on ELF platforms which = support=20 shared libraries.
--cref=20
Output a cross reference table. If a linker map file is being = generated,=20 the cross reference table is printed to the map file. Otherwise, it is = printed=20 on the standard output. The format of the table is intentionally = simple, so=20 that it may be easily processed by a script if necessary. The symbols = are=20 printed out, sorted by name. For each symbol, a list of file names is = given.=20 If the symbol is defined, the first file listed is the location of the = definition. The remaining files contain references to the symbol.
--defsym symbol=3Dexpression=20
Create a global symbol in the output file, containing the absolute = address=20 given by expression. You may use this option as many times = as=20 necessary to define multiple symbols in the command line. A limited = form of=20 arithmetic is supported for the expression in this context: = you may=20 give a hexadecimal constant or the name of an existing symbol, or use=20 + and - to add or subtract hexadecimal = constants or=20 symbols. If you need more elaborate expressions, consider using the = linker=20 command language from a script (see section Assignment:=20 Defining Symbols). Note: there should be no white space = between=20 symbol, the equals sign ("=3D"), and=20 expression.
--dynamic-linker file=20
Set the name of the dynamic linker. This is only meaningful when=20 generating dynamically linked ELF executables. The default dynamic = linker is=20 normally correct; don't use this unless you know what you are doing. =
-EB=20
Link big-endian objects. This affects the default output format. =
-EL=20
Link little-endian objects. This affects the default output = format.
--embedded-relocs=20
This option is only meaningful when linking MIPS embedded PIC = code,=20 generated by the -membedded-pic option to the GNU compiler and = assembler. It=20 causes the linker to create a table which may be used at runtime to = relocate=20 any data which was statically initialized to pointer values. See the = code in=20 testsuite/ld-empic for details.
--help=20
Print a summary of the command-line options on the standard output = and=20 exit.
-Map mapfile=20
Print a link map to the file mapfile. See the = description of=20 the `-M' option, above.
--no-keep-memory=20
ld normally optimizes for speed over memory usage by = caching=20 the symbol tables of input files in memory. This option tells = ld=20 to instead optimize for memory usage, by rereading the symbol tables = as=20 necessary. This may be required if ld runs out of memory = space=20 while linking a large executable.
--no-warn-mismatch=20
Normally ld will give an error if you try to link = together=20 input files that are mismatched for some reason, perhaps because they = have=20 been compiled for different processors or for different endiannesses. = This=20 option tells ld that it should silently permit such = possible=20 errors. This option should only be used with care, in cases when you = have=20 taken some special action that ensures that the linker errors are=20 inappropriate.
--no-whole-archive=20
Turn off the effect of the --whole-archive option for = subsequent archive files.
--noinhibit-exec=20
Retain the executable output file whenever it is still usable. = Normally,=20 the linker will not produce an output file if it encounters errors = during the=20 link process; it exits without writing an output file when it issues = any error=20 whatsoever.
--oformat output-format=20
ld may be configured to support more than one kind of = object=20 file. If your ld is configured this way, you can use the=20 `--oformat' option to specify the binary format for the = output=20 object file. Even when ld is configured to support = alternative=20 object formats, you don't usually need to specify this, as = ld=20 should be configured to produce as a default output format the most = usual=20 format on each machine. output-format is a text string, the = name of=20 a particular format supported by the BFD libraries. (You can list the=20 available binary formats with `objdump -i'.) The script = command=20 OUTPUT_FORMAT can also specify the output format, but = this option=20 overrides it. See section BFD.=20
-qmagic=20
This option is ignored for Linux compatibility.
-Qy=20
This option is ignored for SVR4 compatibility.
--relax=20
An option with machine dependent effects. This option is only = supported on=20 a few targets. See section ld=20 and the H8/300. See section ld=20 and the Intel 960 family. On some platforms, the = `--relax'=20 option performs global optimizations that become possible when the = linker=20 resolves addressing in the program, such as relaxing address modes and = synthesizing new instructions in the output object file. On platforms = where=20 this is not supported, `--relax' is accepted, but = ignored.
--retain-symbols-file filename=20
Retain only the symbols listed in the file = filename,=20 discarding all others. filename is simply a flat file, with = one=20 symbol name per line. This option is especially useful in environments = (such=20 as VxWorks) where a large global symbol table is accumulated = gradually, to=20 conserve run-time memory. `--retain-symbols-file' does=20 not discard undefined symbols, or symbols needed for = relocations. You=20 may only specify `--retain-symbols-file' once in the = command=20 line. It overrides `-s' and `-S'.=20
-rpath dir=20
Add a directory to the = runtime=20 library search path. This is used when linking an ELF executable with = shared=20 objects. All -rpath arguments are concatenated and passed = to the=20 runtime linker, which uses them to locate shared objects at runtime. = The=20 -rpath option is also used when locating shared objects = which are=20 needed by shared objects explicitly included in the link; see the = description=20 of the -rpath-link option. If -rpath is not = used=20 when linking an ELF executable, the contents of the environment = variable=20 LD_RUN_PATH will be used if it is defined. The=20 -rpath option may also be used on SunOS. By default, on = SunOS,=20 the linker will form a runtime search patch out of all the = -L=20 options it is given. If a -rpath option is used, the = runtime=20 search path will be formed exclusively using the -rpath = options,=20 ignoring the -L options. This can be useful when using = gcc, which=20 adds many -L options which may be on NFS mounted = filesystems. For=20 compatibility with other ELF linkers, if the -R option is = followed by a directory name, rather than a file name, it is treated = as the=20 -rpath option.
-rpath-link DIR=20
When using ELF or SunOS, one shared library may require another. = This=20 happens when an ld -shared link includes a shared library = as one=20 of the input files. When the linker encounters such a dependency when = doing a=20 non-shared, non-relocateable link, it will automatically try to locate = the=20 required shared library and include it in the link, if it is not = included=20 explicitly. In such a case, the -rpath-link option = specifies the=20 first set of directories to search. The -rpath-link = option may=20 specify a sequence of directory names either by specifying a list of = names=20 separated by colons, or by appearing multiple times. The linker uses = the=20 following search paths to locate required shared libraries.=20
  1. Any directories specified by -rpath-link options.=20
  2. Any directories specified by -rpath options. The = difference=20 between -rpath and -rpath-link is that = directories=20 specified by -rpath options are included in the = executable and=20 used at runtime, whereas the -rpath-link option is only = effective at link time.=20
  3. On an ELF system, if the -rpath and = rpath-link=20 options were not used, search the contents of the environment = variable=20 LD_RUN_PATH.=20
  4. On SunOS, if the -rpath option was not used, search = any=20 directories specified using -L options.=20
  5. For a native linker, the contents of the environment variable=20 LD_LIBRARY_PATH.=20
  6. The default directories, normally `/lib' and=20 `/usr/lib'.
If the required shared library is not = found,=20 the linker will issue a warning and continue with the link.
-shared=20
-Bshareable=20
Create a shared library. This is currently = only=20 supported on ELF, XCOFF and SunOS platforms. On SunOS, the linker will = automatically create a shared library if the -e option is = not=20 used and there are undefined symbols in the link.=20
--sort-common=20
This option tells ld to sort the = common=20 symbols by size when it places them in the appropriate output = sections. First=20 come all the one byte symbols, then all the two bytes, then all the = four=20 bytes, and then everything else. This is to prevent gaps between = symbols due=20 to alignment constraints.
--split-by-file=20
Similar to --split-by-reloc but creates a new output = section=20 for each input file.
--split-by-reloc count=20
Trys to creates extra sections in the output file so that no = single output=20 section in the file contains more than count relocations. = This is=20 useful when generating huge relocatable for downloading into certain = real time=20 kernels with the COFF object file format; since COFF cannot represent = more=20 than 65535 relocations in a single section. Note that this will fail = to work=20 with object file formats which do not support arbitrary sections. The = linker=20 will not split up individual input sections for redistribution, so if = a single=20 input section contains more than count relocations one = output=20 section will contain that many relocations.
--stats=20
Compute and display statistics about the operation of the linker, = such as=20 execution time and memory usage.
--traditional-format=20
For some targets, the output of ld is different in = some ways=20 from the output of some existing linker. This switch requests = ld=20 to use the traditional format instead. For = example, on=20 SunOS, ld combines duplicate entries in the symbol string = table.=20 This can reduce the size of an output file with full debugging = information by=20 over 30 percent. Unfortunately, the SunOS dbx program can = not=20 read the resulting program (gdb has no trouble). The=20 `--traditional-format' switch tells ld to = not=20 combine duplicate entries.
-Tbss org=20
-Tdata org=20
-Ttext org=20
Use org as the starting address for--respectively--the=20 bss, data, or the text segment = of the=20 output file. org must be a single hexadecimal integer; for=20 compatibility with other linkers, you may omit the leading = `0x'=20 usually associated with hexadecimal values.
-Ur=20
For anything other than C++ programs, this option is equivalent to = `-r': it generates relocatable output--i.e., an output = file that=20 can in turn serve as input to ld. When linking C++ = programs,=20 `-Ur' does resolve references to constructors, = unlike=20 `-r'. It does not work to use `-Ur' on files = that=20 were themselves linked with `-Ur'; once the constructor = table has=20 been built, it cannot be added to. Use `-Ur' only for the = last=20 partial link, and `-r' for the others.
--verbose=20
Display the version number for ld and list the linker = emulations supported. Display which input files can and cannot be = opened.=20 Display the linker script if using a default builtin script.
--version-script=3Dversion-scriptfile=20
Specify the name of a version script to the linker. This is = typically used=20 when creating shared libraries to specify additional information about = the=20 version heirarchy for the library being created. This option is only=20 meaningful on ELF platforms which support shared libraries. See = section Version=20 Script.
--warn-common=20
Warn when a common symbol is combined with another common symbol = or with a=20 symbol definition. Unix linkers allow this somewhat sloppy practice, = but=20 linkers on some other operating systems do not. This option allows you = to find=20 potential problems from combining global symbols. Unfortunately, some = C=20 libraries use this practice, so you may get some warnings about = symbols in the=20 libraries as well as in your programs. There are three kinds of global = symbols, illustrated here by C examples:=20
`int i =3D 1;'=20
A definition, which goes in the initialized data section of the = output=20 file.=20
`extern int i;'=20
An undefined reference, which does not allocate space. There = must be=20 either a definition or a common symbol for the variable somewhere.=20
`int i;'=20
A common symbol. If there are only (one or more) common symbols = for a=20 variable, it goes in the uninitialized data area of the output file. = The=20 linker merges multiple common symbols for the same variable into a = single=20 symbol. If they are of different sizes, it picks the largest size. = The=20 linker turns a common symbol into a declaration, if there is a = definition of=20 the same variable.
The `--warn-common' option = can=20 produce five kinds of warnings. Each warning consists of a pair of = lines: the=20 first describes the symbol just encountered, and the second describes = the=20 previous symbol encountered with the same name. One or both of the two = symbols=20 will be a common symbol.=20
  1. Turning a common symbol into a reference, because there is = already a=20 definition for the symbol. 
    file(section): =
warning: common of `symbol'
   overridden by definition
file(section): warning: defined here
  2. Turning a common symbol into a reference, because a later = definition for=20 the symbol is encountered. This is the same as the previous case, = except=20 that the symbols are encountered in a different order. = 
    file(section): warning: definition of =
`symbol'
   overriding common
file(section): warning: common is here
  3. Merging a common symbol with a previous same-sized common = symbol. 
    file(section): warning: multiple =
common
   of `symbol'
file(section): warning: previous common is here
  4. Merging a common symbol with a previous larger common symbol. = 
    file(section): warning: common of =
`symbol'
   overridden by larger common
file(section): warning: larger common is here
  5. Merging a common symbol with a previous smaller common symbol. = This is=20 the same as the previous case, except that the symbols are = encountered in a=20 different order. 
    file(section): warning: =
common of `symbol'
   overriding smaller common
file(section): warning: smaller common is here
--warn-constructors=20
Warn if any global constructors are used. This is only useful for = a few=20 object file formats. For formats like COFF or ELF, the linker can not = detect=20 the use of global constructors.
--warn-multiple-gp=20
Warn if multiple global pointer values are required in the output = file.=20 This is only meaningful for certain processors, such as the Alpha.=20 Specifically, some processors put large-valued constants in a special = section.=20 A special register (the global pointer) points into the middle of this = section, so that constants can be loaded efficiently via a = base-register=20 relative addressing mode. Since the offset in base-register relative = mode is=20 fixed and relatively small (e.g., 16 bits), this limits the maximum = size of=20 the constant pool. Thus, in large programs, it is often necessary to = use=20 multiple global pointer values in order to be able to address all = possible=20 constants. This option causes a warning to be issued whenever this = case=20 occurs.
--warn-once=20
Only warn once for each undefined symbol, rather than once per = module=20 which refers to it.
--warn-section-align=20
Warn if the address of an output section is changed because of = alignment.=20 Typically, the alignment will be set by an input section. The address = will=20 only be changed if it not explicitly specified; that is, if the=20 SECTIONS command does not specify a start address for the = section=20 (see section Specifying=20 Output Sections).
--whole-archive=20
For each archive mentioned on the command line after the=20 --whole-archive option, include every object file in the = archive=20 in the link, rather than searching the archive for the required object = files.=20 This is normally used to turn an archive file into a shared library, = forcing=20 every object to be included in the resulting shared library. This = option may=20 be used more than once.
--wrap symbol=20
Use a wrapper function for symbol. Any undefined = reference to=20 symbol will be resolved to = __wrap_symbol.=20 Any undefined reference to __real_symbol will = be=20 resolved to symbol. This can be used to provide a wrapper = for a=20 system function. The wrapper function should be called=20 __wrap_symbol. If it wishes to call the system = function, it should call __real_symbol. Here = is a=20 trivial example: 
void *
__wrap_malloc (int c)
{
  printf ("malloc called with %ld\n", c);
  return __real_malloc (c);
}
If you link other code with this file using --wrap = malloc,=20 then all calls to malloc will call the function=20 __wrap_malloc instead. The call to = __real_malloc in=20 __wrap_malloc will call the real malloc = function.=20 You may wish to provide a __real_malloc function as well, = so that=20 links without the --wrap option will succeed. If you do = this, you=20 should not put the definition of __real_malloc in the = same file=20 as __wrap_malloc; if you do, the assembler may resolve = the call=20 before the linker has a chance to wrap it to malloc. =

Environment Variables

You can change the behavior of ld with the environment = variables=20 GNUTARGET and LDEMULATION.

GNUTARGET = determines the=20 input-file object format if you don't use `-b' (or its = synonym=20 `--format'). Its value should be one of the BFD names for = an input=20 format (see section BFD).=20 If there is no GNUTARGET in the environment, = ld uses=20 the natural format of the target. If GNUTARGET is set to=20 default then BFD attempts to discover the input format by = examining=20 binary input files; this method often succeeds, but there are potential=20 ambiguities, since there is no method of ensuring that the magic number = used to=20 specify object-file formats is unique. However, the configuration = procedure for=20 BFD on each system places the conventional format for that system first = in the=20 search-list, so ambiguities are resolved in favor of convention.

LDEMULATION determines the default = emulation if you=20 don't use the `-m' option. The emulation can affect various = aspects=20 of linker behaviour, particularly the default linker script. You can = list the=20 available emulations with the `--verbose' or = `-V'=20 options. If the `-m' option is not used, and the=20 LDEMULATION environment variable is not defined, the = default=20 emulation depends upon how the linker was configured.

Command Language

The command language provides explicit control = over the=20 link process, allowing complete specification of the mapping between the = linker's input files and its output. It controls:=20

You may supply a command file (also known as a linker script) to the = linker=20 either explicitly through the `-T' option, or implicitly as = an=20 ordinary file. Normally you should use the `-T' option. An = implicit=20 linker script should only be used when you want to augment, rather than = replace,=20 the default linker script; typically an implicit linker script would = consist=20 only of INPUT or GROUP commands.

If the linker opens a file which it cannot recognize as a supported = object or=20 archive format, nor as a linker script, it reports an error.

Linker Scripts

The ld command language is a collection of statements; = some are=20 simple keywords setting a particular option, some are used to select and = group=20 input files or name output files; and two statement types have a = fundamental and=20 pervasive impact on the linking process.

The most fundamental command of the ld = command=20 language is the SECTIONS command (see section Specifying=20 Output Sections). Every meaningful command script must have a=20 SECTIONS command: it specifies a "picture" of the output = file's=20 layout, in varying degrees of detail. No other command is required in = all cases.=20

The MEMORY command complements SECTIONS by=20 describing the available memory in the target architecture. This command = is=20 optional; if you don't use a MEMORY command, = ld=20 assumes sufficient memory is available in a contiguous block for all = output. See=20 section Memory=20 Layout.

You may include comments in linker scripts just = as in C:=20 delimited by `/*' and `*/'. As in C, comments = are=20 syntactically equivalent to whitespace.

Expressions

Many useful commands = involve arithmetic=20 expressions. The syntax for expressions in the command language is = identical to=20 that of C expressions, with the following features:=20

Integers

An octal integer is = `0'=20 followed by zero or more of the octal digits (`01234567'). = 

_as_octal =3D 0157255;

A decimal integer starts with a non-zero digit = followed by=20 zero or more digits (`0123456789'). 

_as_decimal =3D =
57005;

A hexadecimal integer is=20 `0x' or `0X' followed by one or more = hexadecimal=20 digits chosen from `0123456789abcdefABCDEF'. 

_as_hex =
=3D 0xdead;

To write a negative integer, use the prefix = operator=20 `-' (see section Operators).=20 

_as_neg =3D -57005;

Additionally the suffixes = K and=20 M may be used to scale a constant by respectively. For = example, the=20 following all refer to the same quantity: 

        _fourk_1 =3D =
4K;
        _fourk_2 =3D 4096;
        _fourk_3 =3D 0x1000;

Symbol Names

Unless quoted, symbol names start with a letter, = underscore, or=20 point and may include any letters, underscores, digits, points, and = hyphens.=20 Unquoted symbol names must not conflict with any keywords. You can = specify a=20 symbol which contains odd characters or has the same name as a keyword, = by=20 surrounding the symbol name in double quotes: 

        "SECTION" =3D =
9;
        "with a space" =3D "also with a space" + 10;

Since symbols can contain many non-alphabetic characters, it is = safest to=20 delimit symbols with spaces. For example, `A-B' is one = symbol,=20 whereas `A - B' is an expression involving subtraction. =

The Location Counter

The special linker variable dot = `.' always=20 contains the current output location counter. Since the . = always=20 refers to a location in an output section, it must always appear in an=20 expression within a SECTIONS command. The . = symbol may=20 appear anywhere that an ordinary symbol is allowed in an expression, but = its=20 assignments have a side effect. Assigning a value to the . = symbol=20 will cause the location counter to be moved. This = may be used=20 to create holes in the output section. The location counter may never be = moved=20 backwards. 

SECTIONS
{
  output :
  {
  file1(.text)
  . =3D . + 1000;
  file2(.text)
  . +=3D 1000;
  file3(.text)
  } =3D 0x1234;
}

In the previous example, file1 is located at the = beginning of=20 the output section, then there is a 1000 byte gap. Then = file2=20 appears, also with a 1000 byte gap following before file3 = is=20 loaded. The notation `=3D 0x1234' specifies what data to = write in the=20 gaps (see section Optional=20 Section Attributes).

@vfill

Operators

The = linker=20 recognizes the standard C set of arithmetic operators, with the standard = bindings and precedence levels: { = @obeylines@parskip=3D0pt@parindent=3D0pt @dag@quad=20 Prefix operators. @ddag@quad See section Assignment:=20 Defining Symbols. }

Evaluation

The linker uses "lazy = evaluation" for=20 expressions; it only calculates an expression when absolutely necessary. = The=20 linker needs the value of the start address, and the lengths of memory = regions,=20 in order to do any linking at all; these values are computed as soon as = possible=20 when the linker reads in the command file. However, other values (such = as symbol=20 values) are not known or needed until after storage allocation. Such = values are=20 evaluated later, when other information (such as the sizes of output = sections)=20 is available for use in the symbol assignment expression.

Assignment: Defining Symbols

You = may create=20 global symbols, and assign values (addresses) to global symbols, using = any of=20 the C assignment operators:

symbol =3D expression ;=20
symbol &=3D expression ;=20
symbol +=3D expression ;=20
symbol -=3D expression ;=20
symbol *=3D expression ;=20
symbol /=3D expression ;=20

Two things distinguish assignment from other operators in = ld=20 expressions.=20

Assignment statements may appear:=20

The first two cases are equivalent in effect--both define a symbol = with an=20 absolute address. The last case defines a symbol whose address is = relative to a=20 particular section (see section Specifying=20 Output Sections).

When a = linker=20 expression is evaluated and assigned to a variable, it is given either = an=20 absolute or a relocatable type. An absolute expression type is one in = which the=20 symbol contains the value that it will have in the output file; a = relocatable=20 expression type is one in which the value is expressed as a fixed offset = from=20 the base of a section.

The type of the expression is controlled by its position in the = script file.=20 A symbol assigned within a section definition is created relative to the = base of=20 the section; a symbol assigned in any other place is created as an = absolute=20 symbol. Since a symbol created within a section definition is relative = to the=20 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=20 within a section definition by using the absolute assignment function=20 ABSOLUTE. For example, to create an absolute symbol whose = address=20 is the last byte of an output section named .data: = 

SECTIONS{ ...
  .data :=20
    {
      *(.data)
      _edata =3D ABSOLUTE(.) ;
    }=20
... }

The linker tries to put off the evaluation of an assignment until all = the=20 terms in the source expression are known (see section Evaluation).=20 For instance, the sizes of sections cannot be known until after = allocation, so=20 assignments dependent upon these are not performed until after = allocation. Some=20 expressions, such as those depending upon the location counter = dot,=20 `.' must be evaluated during allocation. If the result of = an=20 expression is required, but the value is not available, then an error = results.=20 For example, a script like the following 

SECTIONS { ...
  text 9+this_isnt_constant :=20
    { ...
    }
... }

will cause the error message "Non constant = expression for initial address".

In some cases, it is desirable for a linker = script to=20 define a symbol only if it is referenced, and only if it is not defined = by any=20 object included in the link. For example, traditional linkers defined = the symbol=20 `etext'. However, ANSI C requires that the user be able to = use=20 `etext' as a function name without encountering an error. = The=20 PROVIDE keyword may be used to define a symbol, such as=20 `etext', only if it is referenced but not defined. The = syntax is=20 PROVIDE(symbol =3D expression).

Arithmetic Functions

The command language includes a number of = built-in=20 functions for use in link script expressions.=20

ABSOLUTE(exp)=20
Return the absolute=20 (non-relocatable, as opposed to non-negative) value of the expression=20 exp. Primarily useful to assign an absolute value to a = symbol=20 within a section definition, where symbol values are normally=20 section-relative.
ADDR(section)=20
Return the absolute address of the named section. Your = script=20 must previously have defined the location of that section. In the = following=20 example, symbol_1 and symbol_2 are assigned=20 identical values: 
SECTIONS{ ...
  .output1 :
    {=20
    start_of_output_1 =3D ABSOLUTE(.);
    ...
    }
  .output :
    {
    symbol_1 =3D ADDR(.output1);
    symbol_2 =3D start_of_output_1;
    }
... }
LOADADDR(section)=20
Return the absolute load address of the named section. = This is=20 normally the same as ADDR, but it may be different if the = AT keyword is used in the section definition (see section = Optional=20 Section Attributes).
ALIGN(exp)=20
Return the result of the current location counter (.) = aligned=20 to the next exp boundary. exp must be an = expression=20 whose value is a power of two. This is equivalent to 
(. + =
exp - 1) & ~(exp - 1)
ALIGN doesn't change the value of the location = counter--it=20 just does arithmetic on it. As an example, to align the output=20 .data section to the next 0x2000 byte = boundary after=20 the preceding section and to set a variable within the section to the = next=20 0x8000 boundary after the input sections: 
SECTIONS{ =
...
  .data ALIGN(0x2000): {
    *(.data)
    variable =3D ALIGN(0x8000);
  }
... }
The first use of ALIGN in this example specifies the=20 location of a section because it is used as the optional = start=20 attribute of a section definition (see section Optional=20 Section Attributes). The second use simply defines the value of a=20 variable. The built-in NEXT is closely related to=20 ALIGN.
DEFINED(symbol)=20
Return 1 if symbol is in the linker global symbol table = and is=20 defined, otherwise return 0. You can use this function to provide = default=20 values for symbols. For example, the following command-file fragment = shows how=20 to set a global symbol begin to the first location in the = .text section--but if a symbol called begin = already=20 existed, its value is preserved: 
SECTIONS{ ...
  .text : {
    begin =3D DEFINED(begin) ? begin : . ;
    ...
  }
... }
NEXT(exp)=20
Return the next unallocated address that is a multiple of = exp.=20 This function is closely related to = ALIGN(exp); unless=20 you use the MEMORY command to define discontinuous memory = for the=20 output file, the two functions are equivalent.
SIZEOF(section)=20
Return the size in bytes of the named section, if that = section=20 has been allocated. In the following example, symbol_1 = and=20 symbol_2 are assigned identical values: 
SECTIONS{ =
...
  .output {
    .start =3D . ;
    ...
    .end =3D . ;
    }
  symbol_1 =3D .end - .start ;
  symbol_2 =3D SIZEOF(.output);
... }
SIZEOF_HEADERS=20
sizeof_headers=20
Return the size in bytes of the output file's headers. You can use = this=20 number as the start address of the first section, if you choose, to = facilitate=20 paging.
MAX(exp1, exp2)=20
Returns the maximum of exp1 and exp2.
MIN(exp1, exp2)=20
Returns the minimum of exp1 and exp2. =

Semicolons

Semicolons (";") are required in the following places. In = all=20 other places they can appear for aesthetic reasons but are otherwise = ignored.=20

Assignment=20
Semicolons must appear at the end of assignment expressions. See = section=20 Assignment:=20 Defining Symbols=20
PHDRS=20
Semicolons must appear at the end of a PHDRS = statement. See=20 section ELF=20 Program Headers

Memory Layout

The linker's default configuration permits allocation = of all=20 available memory. You can override this configuration by using the=20 MEMORY command. The MEMORY command describes = the=20 location and size of blocks of memory in the target. By using it = carefully, you=20 can describe which memory regions may be used by the linker, and which = memory=20 regions it must avoid. The linker does not shuffle sections to fit into = the=20 available regions, but does move the requested sections into the correct = regions=20 and issue errors when the regions become too full.

A command file may contain at most one use of the MEMORY = command; however, you can define as many blocks of memory within it as = you wish.=20 The syntax is: 

MEMORY=20
  {
    name (attr) : ORIGIN =3D origin, =
LENGTH =3D len
    ...
  }
name=20
is a name used internally by the linker to = refer to the=20 region. Any symbol name may be used. The region names are stored in a = separate=20 name space, and will not conflict with symbols, file names or section = names.=20 Use distinct names to specify multiple regions.
(attr)=20
is an optional list of attributes that specify whether to use a = particular=20 memory to place sections that are not listed in the linker script. = Valid=20 attribute lists must be made up of the characters = "ALIRWX" that=20 match section attributes. If you omit the attribute list, you may omit = the=20 parentheses around it as well. The attributes currently supported are: =
`Letter'=20
Section Attribute=20
`R'=20
Read-only sections.=20
`W'=20
Read/write sections.=20
`X'=20
Sections containing executable code.=20
`A'=20
Allocated sections.=20
`I'=20
Initialized sections.=20
`L'=20
Same as I.=20
`!'=20
Invert the sense of any of the following attributes. =
origin=20
is the start address of the region in physical memory. It is an = expression=20 that must evaluate to a constant before memory allocation is = performed. The=20 keyword ORIGIN may be abbreviated to org or=20 o (but not, for example, `ORG').
len=20
is the size in bytes of the region (an expression). The keyword=20 LENGTH may be abbreviated to len or = l.=20

For example, to specify that memory has two regions available for=20 allocation--one starting at 0 for 256 kilobytes, and the other starting = at=20 0x40000000 for four megabytes. The rom memory = region=20 will get all sections without an explicit memory register that are = either=20 read-only or contain code, while the ram memory region will = get the=20 sections. 

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

Once you have defined a region of memory named mem, you = can direct=20 specific output sections there by using a command ending in=20 `>mem' within the SECTIONS = command (see=20 section Optional=20 Section Attributes). If the combined output sections directed to a = region=20 are too big for the region, the linker will issue an error message.

Specifying Output Sections

The SECTIONS command controls = exactly where=20 input sections are placed into output sections, their order in the = output file,=20 and to which output sections they are allocated.

You may use at most one SECTIONS command in a script = file, but=20 you can have as many statements within it as you wish. Statements within = the=20 SECTIONS command can do one of three things:

You can also use the first two operations--defining the entry point = and=20 defining symbols--outside the SECTIONS command: see section = The=20 Entry Point, and section Assignment:=20 Defining Symbols. They are permitted here as well for your = convenience in=20 reading the script, so that symbols and the entry point can be defined = at=20 meaningful points in your output-file layout.

If you do not use a SECTIONS command, the linker places = each=20 input section into an identically named output section in the order that = the=20 sections are first encountered in the input files. If all input sections = are=20 present in the first file, for example, the order of sections in the = output file=20 will match the order in the first input file.

Section Definitions

The most frequently used statement in the=20 SECTIONS command is the section definition, which=20 specifies the properties of an output section: its location, alignment,=20 contents, fill pattern, and target memory region. Most of these = specifications=20 are optional; the simplest form of a section definition is 

SECTIONS =
{ ...
  secname : {
    contents
  }
... }

secname is the name of the output = section, and=20 contents a specification of what goes there--for example, a = list of=20 input files or sections of input files (see section Section=20 Placement). The whitespace around secname is required, so = that=20 the section name is unambiguous. The other whitespace shown is optional. = You do=20 need the colon `:' and the braces `{}', = however.

secname must meet the constraints of your output format. = In=20 formats which only support a limited number of sections, such as=20 a.out, the name must be one of the names supported by the = format=20 (a.out, for example, allows only .text,=20 .data or .bss). If the output format supports = any=20 number of sections, but with numbers and not names (as is the case for = Oasys),=20 the name should be supplied as a quoted numeric string. A section name = may=20 consist of any sequence of characters, but any name which does not = conform to=20 the standard ld symbol name syntax must be quoted. See = section = Symbol=20 Names.

The special secname `/DISCARD/' may be used = to=20 discard input sections. Any sections which are assigned to an output = section=20 named `/DISCARD/' are not included in the final link = output.

The linker will not create output sections which do not have any = contents.=20 This is for convenience when referring to input sections that may or may = not=20 exist. For example, 

.foo { *(.foo) }

will only create a `.foo' section in the output file if = there is=20 a `.foo' section in at least one input file.

Section Placement

In a section definition, you can specify the = contents of=20 an output section by listing particular input files, by listing = particular=20 input-file sections, or by a combination of the two. You can also place=20 arbitrary data in the section, and define symbols relative to the = beginning of=20 the section.

The contents of a section definition may include any of = the=20 following kinds of statement. You can include as many of these as you = like in a=20 single section definition, separated from one another by whitespace. =

filename=20
You = may simply=20 name a particular input file to be placed in the current output = section;=20 all sections from that file are placed in the current section = definition. If the file name has already been mentioned in another = section=20 definition, with an explicit section name list, then only those = sections which=20 have not yet been allocated are used. To specify a list of particular = files by=20 name: 
.data : { afile.o bfile.o cfile.o }
The example also illustrates that multiple statements can be = included in=20 the contents of a section definition, since each file name is a = separate=20 statement.
filename( section )=20
filename( section , = section, ...=20 )=20
filename( section section = ...=20 )=20
You can name one or more sections from your input files, for = insertion in=20 the current output section. If you wish to specify a list of = input-file=20 sections inside the parentheses, separate the section names with = whitespace.=20
* (section)=20
* (section, section, ...)=20
* (section section ...)=20
Instead of explicitly naming particular input files in a link = control=20 script, you can refer to all files from the ld = command=20 line: use `*' instead of a particular file name before = the=20 parenthesized input-file section list. If you have already explicitly = included=20 some files by name, `*' refers to all remaining=20 files--those whose places in the output file have not yet been = defined. For=20 example, to copy sections 1 through 4 from = an Oasys=20 file into the .text section of an a.out = file, and=20 sections 13 and 14 into the = .data=20 section: 
SECTIONS {
  .text :{
    *("1" "2" "3" "4")
  }
 =20
  .data :{
    *("13" "14")
  }
}
`[ section ... ]' = used to be=20 accepted as an alternate way to specify named sections from all = unallocated=20 input files. Because some operating systems (VMS) allow brackets in = file=20 names, that notation is no longer supported.
filename( COMMON )=20
*( COMMON )=20
Specify where in your output file to place uninitialized data with = this=20 notation. *(COMMON) by itself refers to all uninitialized = data=20 from all input files (so far as it is not yet allocated);=20 filename(COMMON) refers to uninitialized data = from a=20 particular file. Both are special cases of the general mechanisms for=20 specifying where to place input-file sections: ld permits = you to=20 refer to uninitialized data as if it were in an input-file section = named=20 COMMON, regardless of the input file's format.

In any place where you may use a specific file or section name, you = may also=20 use a wildcard pattern. The linker handles wildcards much as the Unix = shell=20 does. A `*' character matches any number of characters. A=20 `?' character matches any single character. The sequence=20 `[chars]' will match a single instance of any of = the=20 chars; the `-' character may be used to specify = a range=20 of characters, as in `[a-z]' to match any lower case = letter. A=20 `\' character may be used to quote the following character. =

When a file name is matched with a wildcard, the wildcard characters = will not=20 match a `/' character (used to separate directory names on = Unix). A=20 pattern consisting of a single `*' character is an = exception; it=20 will always match any file name. In a section name, the wildcard = characters will=20 match a `/' character.

Wildcards only match files which are explicitly specified on the = command=20 line. The linker does not search directories to expand wildcards. = However, if=20 you specify a simple file name--a name with no wildcard characters--in a = linker=20 script, and the file name is not also specified on the command line, the = linker=20 will attempt to open the file as though it appeared on the command line. =

In the following example, the command script arranges the output file = into=20 three consecutive sections, named .text, = .data, and=20 .bss, taking the input for each from the correspondingly = named=20 sections of all the input files: 

SECTIONS {=20
  .text : { *(.text) }
  .data : { *(.data) }=20
  .bss :  { *(.bss)  *(COMMON) }=20
}=20

The following example reads all of the sections from file = all.o=20 and places them at the start of output section outputa = which starts=20 at location 0x10000. All of section .input1 = from file=20 foo.o follows immediately, in the same output section. All = of=20 section .input2 from foo.o goes into output = section=20 outputb, followed by section .input1 from=20 foo1.o. All of the remaining .input1 and=20 .input2 sections from any files are written to output = section=20 outputc. 

SECTIONS {
  outputa 0x10000 :
    {
    all.o
    foo.o (.input1)
    }
  outputb :
    {
    foo.o (.input2)
    foo1.o (.input1)
    }
  outputc :
    {
    *(.input1)
    *(.input2)
    }
}

This example shows how wildcard patterns might be used to partition = files.=20 All .text sections are placed in .text, and = all=20 .bss sections are placed in .bss. For all = files=20 beginning with an upper case character, the .data section = is placed=20 into .DATA; for all other files, the .data = section is=20 placed into .data. 

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

Section Data Expressions

The foregoing statements arrange, in your output = file,=20 data originating from your input files. You can also place data directly = in an=20 output section from the link command script. Most of these additional = statements=20 involve expressions (see section = Expressions).=20 Although these statements are shown separately here for ease of = presentation, no=20 such segregation is needed within a section definition in the=20 SECTIONS command; you can intermix them freely with any of = the=20 statements we've just described.

CREATE_OBJECT_SYMBOLS=20
Create a symbol=20 for each input file in the current section, set to the address of the = first=20 byte of data written from that input file. For instance, with=20 a.out files it is conventional to have a symbol for each = input=20 file. You can accomplish this by defining the output = .text=20 section as follows: 
SECTIONS {
  .text 0x2020 :
     {
    CREATE_OBJECT_SYMBOLS
    *(.text)
    _etext =3D ALIGN(0x2000);
    }
  ...
}
If sample.ld is a file containing this script, and=20 a.o, b.o, c.o, and = d.o are=20 four input files with contents like the following--- 
/* a.c */

afunction() { }
int adata=3D1;
int abss;
`ld -M -T sample.ld a.o b.o c.o d.o' would create a = map=20 like this, containing symbols matching the object file names: = 
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
symbol =3D expression ;=20
symbol f=3D expression = ;=20
symbol is any symbol name (see section = Symbol=20 Names). "f=3D" refers to any of the operators = &=3D +=3D -=3D=20 *=3D /=3D which combine arithmetic and assignment. When=20 you assign a value to a symbol within a particular section definition, = the=20 value is relative to the beginning of the section (see section Assignment:=20 Defining Symbols). If you write 
SECTIONS {
  abs =3D 14 ;
  ...
  .data : { ... rel =3D 14 ; ... }
  abs2 =3D 14 + ADDR(.data);
  ...
}
abs and rel do not have the same value;=20 rel has the same value as abs2.
BYTE(expression)=20
SHORT(expression)=20
LONG(expression)=20
QUAD(expression)=20
SQUAD(expression)=20
By including one of these four statements in a section definition, = you can=20 explicitly place one, two, four, eight unsigned, or eight signed bytes = (respectively) at the current address of that section. When using a 64 = bit=20 host or target, QUAD and SQUAD are the same. = When=20 both host and target are 32 bits, QUAD uses an unsigned = 32 bit=20 value, and SQUAD sign extends the value. Both will use = the=20 correct endianness when writing out the value. Multiple-byte = quantities are=20 represented in whatever byte order is appropriate for the output file = format=20 (see section BFD).=20
FILL(expression)=20
Specify the "fill pattern" for the current section. Any otherwise=20 unspecified regions of memory within the section (for example, regions = you=20 skip over by assigning a new value to the location counter = `.')=20 are filled with the two least significant bytes from the = expression=20 argument. A FILL statement covers memory locations = after=20 the point it occurs in the section definition; by including more than = one=20 FILL statement, you can have different fill patterns in = different=20 parts of an output section.

Optional Section Attributes

Here is the full syntax of a section definition, = including=20 all the optional portions: 

SECTIONS {
...
secname start BLOCK(align) (NOLOAD) : =
AT ( ldadr )
  { contents } >region :phdr =
=3Dfill
...
}

secname and contents are required. See section = Section=20 Definitions, and section Section=20 Placement, for details on contents. The remaining=20 elements---start, BLOCK(align),=20 (NOLOAD), AT ( ldadr ),=20 >region, :phdr, and=20 =3Dfill---are all optional.

start=20
You = can force the=20 output section to be loaded at a specified address by specifying=20 start immediately following the section name. = start can=20 be represented as any expression. The following example generates = section=20 output at location 0x40000000: 
SECTIONS {
  ...
  output 0x40000000: {
    ...
    }
  ...
}
BLOCK(align)=20
You can include BLOCK() specification to advance the = location=20 counter . prior to the beginning of the section, so that = the=20 section will begin at the specified alignment. align is an=20 expression.
(NOLOAD)=20
The `(NOLOAD)' directive will mark a section to not = be loaded=20 at run time. The linker will process the section normally, but will = mark it so=20 that a program loader will not load it into memory. For example, in = the script=20 sample below, the ROM section is addressed at memory = location=20 `0' and does not need to be loaded when the program is = run. The=20 contents of the ROM section will appear in the linker = output file=20 as usual. 
SECTIONS {
  ROM  0  (NOLOAD)  : { ... }
  ...
}
AT ( ldadr )=20
The expression ldadr that follows the AT = keyword=20 specifies the load address of the section. The default (if you do not = use the=20 AT keyword) is to make the load address the same as the=20 relocation address. This feature is designed to make it easy to build = a ROM=20 image. For example, this SECTIONS definition creates two = output=20 sections: one called `.text', which starts at=20 0x1000, and one called `.mdata', which is = loaded at=20 the end of the `.text' section even though its relocation = address=20 is 0x2000. The symbol _data is defined with = the=20 value 0x2000: 
SECTIONS
  {
  .text 0x1000 : { *(.text) _etext =3D . ; }
  .mdata 0x2000 :=20
    AT ( ADDR(.text) + SIZEOF ( .text ) )
    { _data =3D . ; *(.data); _edata =3D . ;  }
  .bss 0x3000 :
    { _bstart =3D . ;  *(.bss) *(COMMON) ; _bend =3D . ;}
}
The run-time initialization code (for C programs, usually=20 crt0) for use with a ROM generated this way has to = include=20 something like the following, to copy the initialized data from the = ROM image=20 to its runtime address: 
char *src =3D _etext;
char *dst =3D _data;

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

/* Zero bss */
for (dst =3D _bstart; dst< _bend; dst++)
  *dst =3D 0;
>region=20
Assign this section to a previously defined region of memory. See = section=20 Memory=20 Layout.
:phdr=20
Assign this section to a segment described by a program header. = See=20 section ELF=20 Program Headers. If a section is assigned to one or more segments, = then=20 all subsequent allocated sections will be assigned to those segments = as well,=20 unless they use an explicitly :phdr modifier. = To=20 prevent a section from being assigned to a segment when it would = normally=20 default to one, use :NONE.
=3Dfill=20
Including =3Dfill in a section definition = specifies=20 the initial fill value for that section. You may use any expression to = specify=20 fill. Any unallocated holes in the current output section = when=20 written to the output file will be filled with the two least = significant bytes=20 of the value, repeated as necessary. You can also change the fill = value with a=20 FILL statement in the contents of a section=20 definition.

Overlays

The OVERLAY command provides an easy way to describe = sections=20 which are to be loaded as part of a single memory image but are to be = run at the=20 same memory address. At run time, some sort of overlay manager will copy = the=20 overlaid sections in and out of the runtime memory address as required, = perhaps=20 by simply manipulating addressing bits. This approach can be useful, for = example, when a certain region of memory is faster than another.

The OVERLAY command is used within a = SECTIONS=20 command. It appears as follows: 

  OVERLAY start : [ =
NOCROSSREFS ] AT ( ldaddr )
   {
     secname1 { contents } :phdr =
=3Dfill
     secname2 { contents } :phdr =
=3Dfill
     ...
   } >region :phdr =3Dfill

Everything is optional except OVERLAY (a keyword), and = each=20 section must have a name (secname1 and secname2 = above).=20 The section definitions within the OVERLAY construct are = identical=20 to those within the general SECTIONS contruct (see section = Specifying=20 Output Sections), except that no addresses and no memory regions may = be=20 defined for sections within an OVERLAY.

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=20 starting at the load address used for the OVERLAY as a = whole (as=20 with normal section definitions, the load address is optional, and = defaults to=20 the start address; the start address is also optional, and defaults to=20 .).

If the NOCROSSREFS keyword is used, and there any = references=20 among the sections, the linker will report an error. Since the sections = all run=20 at the same address, it normally does not make sense for one section to = refer=20 directly to another. See section Option=20 Commands.

For each section within the OVERLAY, the linker = automatically=20 defines two symbols. The symbol = __load_start_secname is=20 defined as the starting load address of the section. The symbol=20 __load_stop_secname is defined as the final load = address=20 of the section. Any characters within secname which are not = legal=20 within C identifiers are removed. C (or assembler) code may use these = symbols to=20 move the overlaid sections around as necessary.

At the end of the overlay, the value of . is set to the = start=20 address of the overlay plus the size of the largest section.

Here is an example. Remember that this would appear inside a=20 SECTIONS construct. 

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

This will define both .text0 and .text1 to = start at=20 address 0x1000. .text0 will be loaded at address 0x4000, = and=20 .text1 will be loaded immediately after = .text0. The=20 following symbols will be defined: __load_start_text0,=20 __load_stop_text0, __load_start_text1,=20 __load_stop_text1.

C code to copy overlay .text1 into the overlay area = might look=20 like the following. 

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

Note that the OVERLAY command is just syntactic sugar, = since=20 everything it does can be done using the more basic commands. The above = example=20 could have been written identically as follows. 

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

ELF Program Headers

The ELF object file format uses program headers, which are = read by=20 the system loader and describe how the program should be loaded into = memory.=20 These program headers must be set correctly in order to run the program = on a=20 native ELF system. The linker will create reasonable program headers by = default.=20 However, in some cases, it is desirable to specify the program headers = more=20 precisely; the PHDRS command may be used for this purpose. = When the=20 PHDRS command is used, the linker will not generate any = program=20 headers itself.

The PHDRS command is only meaningful when generating an = ELF=20 output file. It is ignored in other cases. This manual does not describe = the=20 details of how the system loader interprets program headers; for more=20 information, see the ELF ABI. The program headers of an ELF file may be=20 displayed using the `-p' option of the objdump = command.

This is the syntax of the PHDRS command. The words=20 PHDRS, FILEHDR, AT, and=20 FLAGS are keywords. 

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

The name is used only for reference in the = SECTIONS=20 command of the linker script. It does not get put into the output file. =

Certain program header types describe segments of memory which are = loaded=20 from the file by the system loader. In the linker script, the contents = of these=20 segments are specified by directing allocated output sections to be = placed in=20 the segment. To do this, the command describing the output section in = the=20 SECTIONS command should use = `:name', where=20 name is the name of the program header as it appears in the=20 PHDRS command. See section Optional=20 Section Attributes.

It is normal for certain sections to appear in more than one segment. = This=20 merely implies that one segment of memory contains another. This is = specified by=20 repeating `:name', using it once for each = program header=20 in which the section is to appear.

If a section is placed in one or more segments using=20 `:name', then all subsequent allocated sections = which do=20 not specify `:name' are placed in the same = segments.=20 This is for convenience, since generally a whole set of contiguous = sections will=20 be placed in a single segment. To prevent a section from being assigned = to a=20 segment when it would normally default to one, use :NONE. =

The FILEHDR and PHDRS keywords which may = appear=20 after the program header type also indicate contents of the segment of = memory.=20 The FILEHDR keyword means that the segment should include = the ELF=20 file header. The PHDRS keyword means that the segment = should=20 include the ELF program headers themselves.

The type may be one of the following. The numbers indicate = the=20 value of the keyword.

PT_NULL (0)=20
Indicates an unused program header.=20
PT_LOAD (1)=20
Indicates that this program header describes a segment to be = loaded from=20 the file.=20
PT_DYNAMIC (2)=20
Indicates a segment where dynamic linking information can be = found.=20
PT_INTERP (3)=20
Indicates a segment where the name of the program interpreter may = be=20 found.=20
PT_NOTE (4)=20
Indicates a segment holding note information.=20
PT_SHLIB (5)=20
A reserved program header type, defined but not specified by the = ELF ABI.=20
PT_PHDR (6)=20
Indicates a segment where the program headers may be found.=20
expression=20
An expression giving the numeric type of the program header. This = may be=20 used for types not defined above.

It is possible to specify that a segment should be loaded at a = particular=20 address in memory. This is done using an AT expression. = This is=20 identical to the AT command used in the = SECTIONS=20 command (see section Optional=20 Section Attributes). Using the AT command for a program = header=20 overrides any information in the SECTIONS command.

Normally the segment flags are set based on the sections. The=20 FLAGS keyword may be used to explicitly specify the segment = flags.=20 The value of flags must be an integer. It is used to set the=20 p_flags field of the program header.

Here is an example of the use of PHDRS. This shows a = typical set=20 of program headers used on a native ELF system. 

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

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

The Entry Point

The = linker command=20 language includes a command specifically for defining the first = executable=20 instruction in an output file (its entry point). Its argument = is a=20 symbol name: 

ENTRY(symbol)

Like symbol assignments, the ENTRY command may be placed = either=20 as an independent command in the command file, or among the section = definitions=20 within the SECTIONS command--whatever makes the most sense = for your=20 layout.

ENTRY is only one of several ways = of choosing=20 the entry point. You may indicate it in any of the following ways (shown = in=20 descending order of priority: methods higher in the list override = methods lower=20 down).=20

For example, you can use these rules to generate an entry point with = an=20 assignment statement: if no symbol start is defined within = your=20 input files, you can simply define it, assigning it an appropriate = value--- 

start =3D 0x2020;

The example shows an absolute address, but you can use any = expression. For=20 example, if your input object files use some other symbol-name = convention for=20 the entry point, you can just assign the value of whatever symbol = contains the=20 start address to start: 

start =3D other_symbol ;

Version Script

The linker command script includes a command = specifically for=20 specifying a version script, and is only meaningful for ELF platforms = that=20 support shared libraries. A version script can be build directly into = the linker=20 script that you are using, or you can supply the version script as just = another=20 input file to the linker at the time that you link. The command script = syntax=20 is: 

VERSION { version script contents }

The version script can also be specified to the linker by means of = the=20 `--version-script' linker command line option. Version = scripts are=20 only meaningful when creating shared libraries.

The format of the version script itself is identical to that used by = Sun's=20 linker in Solaris 2.5. Versioning is done by defining a tree of version = nodes=20 with the names and interdependencies specified in the version script. = The=20 version script can specify which symbols are bound to which version = nodes, and=20 it can reduce a specified set of symbols to local scope so that they are = not=20 globally visible outside of the shared library.

The easiest way to demonstrate the version script language is with a = few=20 examples. 

VERS_1.1 {
	 global:
		 foo1;
	 local:
		 old*;=20
		 original*;=20
		 new*;=20
};

VERS_1.2 {
		 foo2;
} VERS_1.1;

VERS_2.0 {
		 bar1; bar2;
} VERS_1.2;

In this example, three version nodes are defined. = `VERS_1.1' is=20 the first version node defined, and has no other dependencies. The = symbol=20 `foo1' is bound to this version node, and a number of = symbols that=20 have appeared within various object files are reduced in scope to local = so that=20 they are not visible outside of the shared library.

Next, the node `VERS_1.2' is defined. It depends upon=20 `VERS_1.1'. The symbol `foo2' is bound to this = version=20 node.

Finally, the node `VERS_2.0' is defined. It depends upon = `VERS_1.2'. The symbols `bar1' and = `bar2'=20 are bound to this version node.

Symbols defined in the library which aren't specifically bound to a = version=20 node are effectively bound to an unspecified base version of the = library. It is=20 possible to bind all otherwise unspecified symbols to a given version = node using=20 `global: *' somewhere in the version script.

Lexically the names of the version nodes have no specific meaning = other than=20 what they might suggest to the person reading them. The = `2.0'=20 version could just as well have appeared in between `1.1' = and=20 `1.2'. However, this would be a confusing way to write a = version=20 script.

When you link an application against a shared library that has = versioned=20 symbols, the application itself knows which version of each symbol it = requires,=20 and it also knows which version nodes it needs from each shared library = it is=20 linked against. Thus at runtime, the dynamic loader can make a quick = check to=20 make sure that the libraries you have linked against do in fact supply = all of=20 the version nodes that the application will need to resolve all of the = dynamic=20 symbols. In this way it is possible for the dynamic linker to know with=20 certainty that all external symbols that it needs will be resolvable = without=20 having to search for each symbol reference.

The symbol versioning is in effect a much more sophisticated way of = doing=20 minor version checking that SunOS does. The fundamental problem that is = being=20 addressed here is that typically references to external functions are = bound on=20 an as-needed basis, and are not all bound when the application starts = up. If a=20 shared library is out of date, a required interface may be missing; when = the=20 application tries to use that interface, it may suddenly and = unexpectedly fail.=20 With symbol versioning, the user will get a warning when they start = their=20 program if the libraries being used with the application are too old. =

There are several GNU extensions to Sun's versioning approach. The = first of=20 these is the ability to bind a symbol to a version node in the source = file where=20 the symbol is defined instead of in the versioning script. This was done = mainly=20 to reduce the burden on the library maintainer. This can be done by = putting=20 something like: 

__asm__(".symver original_foo,foo@VERS_1.1");

in the C source file. This renamed the function = `original_foo'=20 to be an alias for `foo' bound to the version node=20 `VERS_1.1'. The `local:' directive can be used = to=20 prevent the symbol `original_foo' from being exported.

The second GNU extension is to allow multiple versions of the same = function=20 to appear in a given shared library. In this way an incompatible change = to an=20 interface can take place without increasing the major version number of = the=20 shared library, while still allowing applications linked against the old = interface to continue to function.

This can only be accomplished by using multiple = `.symver'=20 directives in the assembler. An example of this would be: = 

__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");

In this example, `foo@' represents the symbol = `foo'=20 bound to the unspecified base version of the symbol. The source file = that=20 contains this example would define 4 C functions: = `original_foo',=20 `old_foo', `old_foo1', and = `new_foo'.=20

When you have multiple definitions of a given symbol, there needs to = be some=20 way to specify a default version to which external references to this = symbol=20 will be bound. This can be accomplished with the = `foo@@VERS_2.0'=20 type of `.symver' directive. Only one version of a symbol = can be=20 declared 'default' in this manner - otherwise you would effectively have = multiple definitions of the same symbol.

If you wish to bind a reference to a specific version of the symbol = within=20 the shared library, you can use the aliases of convenience (i.e.=20 `old_foo'), or you can use the `.symver' = directive to=20 specifically bind to an external version of the function in question. =

Option Commands

The command language includes a number of other commands that you can = use for=20 specialized purposes. They are similar in purpose to command-line = options.

CONSTRUCTORS=20
When linking=20 using the a.out object file format, the linker uses an = unusual=20 set construct to support C++ global constructors and destructors. When = linking=20 object file formats which do not support arbitrary sections, such as=20 ECOFF and XCOFF, the linker will = automatically=20 recognize C++ global constructors and destructors by name. For these = object=20 file formats, the CONSTRUCTORS command tells the linker = where=20 this information should be placed. The CONSTRUCTORS = command is=20 ignored for other object file formats. The symbol = __anuals/ld-2.9.1/html_mono/ld.html#IDX195= ">expression=20 syntax=20
  • expression,=20 absolute=20
  • expressions=20 in a section

    • f

  • fatal=20 signal=20
  • filename=20
  • filename=20 symbols=20
  • filename(section)=20
  • files=20 and sections, section defn=20
  • files,=20 including in output sections=20
  • fill=20 pattern, entire section=20
  • FILL(expression)=20
  • first=20 input file=20
  • first=20 instruction=20
  • FLOAT=20
  • FORCE_COMMON_ALLOCATION=20
  • FORMAT=20 (MRI)=20
  • format,=20 output file=20
  • functions=20 in expression language=20
  • fundamental=20 script commands

    • g

  • = GNU=20 linker=20
  • GNUTARGET,=20 GNUTARGET=20
  • GROUP (=20 files )=20
  • grouping=20 input files=20
  • groups=20 of archives

    • h

  • H8/300=20 support=20
  • header=20 size=20
  • help=20
  • hexadecimal=20 integers=20
  • holes=20
  • holes,=20 filling

    • i

  • i960=20 support=20
  • INCLUDE=20 filename=20
  • including=20 a linker script=20
  • including=20 an entire archive=20
  • incremental=20 link=20
  • INPUT (=20 files )=20
  • input=20 file format=20
  • input=20 filename symbols=20
  • input=20 files, displaying=20
  • input=20 files, section defn=20
  • input=20 format, input=20 format=20
  • input=20 sections to output section=20
  • integer=20 notation=20
  • integer=20 suffixes=20
  • internal=20 object-file format=20
  • invalid=20 input

    • k

  • K and M=20 integer suffixes

    • l

  • l =3D=20
  • L,=20 deleting symbols beginning=20
  • layout=20 of output file=20
  • lazy=20 evaluation=20
  • ld=20 bugs, reporting=20
  • LDEMULATION=20
  • len=20 =3D=20
  • LENGTH=20 =3D=20
  • link=20 map=20
  • link-time=20 runtime library search path=20
  • linker=20 crash=20
  • LIST=20 (MRI)=20
  • little-endian=20 objects=20
  • LOAD=20 (MRI)=20
  • load=20 address, specifying=20
  • LOADADDR(section)=20
  • loading,=20 preventing=20
  • local=20 symbols, deleting=20
  • location=20 counter=20
  • LONG(expression)=20

    • m

  • M and K=20 integer suffixes=20
  • machine=20 architecture, output=20
  • machine=20 dependencies=20
  • MAX=20
  • MEMORY=20
  • memory=20 region attributes=20
  • memory=20 regions and sections=20
  • memory=20 usage=20
  • MIN=20
  • MIPS=20 embedded PIC code=20
  • MRI=20 compatibility

    • n

  • NAME=20 (MRI)=20
  • names=20
  • naming=20 memory regions=20
  • naming=20 output sections=20
  • naming=20 the output file, naming=20 the output file=20
  • negative=20 integers=20
  • NEXT(exp)=20
  • NMAGIC=20
  • NOCROSSREFS=20 ( sections )=20
  • NOFLOAT=20
  • NOLOAD=20
  • Non=20 constant expression

    • o

  • o =3D=20
  • objdump=20 -i=20
  • object=20 file management=20
  • = object=20 files=20
  • object=20 formats available=20
  • object=20 size=20
  • octal=20 integers=20
  • OMAGIC=20
  • opening=20 object files=20
  • Operators=20 for arithmetic=20
  • = options=20
  • ORDER=20 (MRI)=20
  • org=20 =3D=20
  • ORIGIN=20 =3D=20
  • OUTPUT=20 ( filename )=20
  • output=20 file after errors=20
  • output=20 file layout=20
  • OUTPUT_ARCH=20 ( bfdname )=20
  • OUTPUT_FORMAT=20 ( bfdname )=20
  • OVERLAY=20
  • overlays=20

    • p

  • partial=20 link=20
  • path=20 for libraries=20
  • PHDRS=20
  • precedence=20 in expressions=20
  • prevent=20 unnecessary loading=20
  • program=20 headers=20
  • program=20 headers and sections=20
  • provide=20
  • PUBLIC=20 (MRI)

    • q

  • QUAD(expression)=20
  • quoted=20 symbol names

    • r

  • read-only=20 text=20
  • read/write=20 from cmd line=20
  • regions=20 of memory=20
  • relaxing=20 addressing modes=20
  • relaxing=20 on H8/300=20
  • relaxing=20 on i960=20
  • relocatable=20 and absolute symbols=20
  • relocatable=20 output=20
  • reporting=20 bugs in ld=20
  • requirements=20 for BFD=20
  • retaining=20 specified symbols=20
  • rounding=20 up location counter=20
  • runtime=20 library name=20
  • runtime=20 library search path

    • s

  • scaled=20 integers=20
  • script=20 files=20
  • search=20 directory, from cmd line=20
  • search=20 path, libraries=20
  • SEARCH_DIR=20 ( path )=20
  • SECT=20 (MRI)=20
  • section=20 address, section=20 address=20
  • section=20 alignment=20
  • section=20 alignment, warnings on=20
  • section=20 definition=20
  • section=20 defn, full syntax=20
  • section=20 fill pattern=20
  • section=20 load address=20
  • section=20 size=20
  • section=20 start=20
  • section,=20 assigning to memory region=20
  • section,=20 assigning to program header=20
  • SECTIONS=20
  • segment=20 origins, cmd line=20
  • semicolon=20
  • shared=20 libraries=20
  • SHORT(expression)=20
  • SIZEOF(section)=20
  • sizeof_headers=20
  • SIZEOF_HEADERS=20
  • specify=20 load address=20
  • SQUAD(expression)=20
  • = standard=20 Unix system=20
  • start=20 address, section=20
  • start=20 of execution=20
  • STARTUP=20 ( filename )=20
  • strip=20 all symbols=20
  • strip=20 debugger symbols=20
  • stripping=20 all but some symbols=20
  • suffixes=20 for integers=20
  • symbol=20 defaults=20
  • symbol=20 definition, scripts=20
  • symbol=20 names=20
  • symbol=20 tracing=20
  • symbol=20 versions=20
  • symbol-only=20 input=20
  • symbol=20 =3D expression ;=20
  • symbol=20 f=3D expression ;=20
  • symbols,=20 from command line=20
  • symbols,=20 relocatable and absolute=20
  • symbols,=20 retaining selectively=20
  • synthesizing=20 linker=20
  • synthesizing=20 on H8/300

    • t

  • TARGET=20 ( format )=20
  • traditional=20 format

    • u

  • unallocated=20 address, next=20
  • undefined=20 symbol=20
  • undefined=20 symbols, warnings on=20
  • uninitialized=20 data=20
  • unspecified=20 memory=20
  • usage=20

    • v

  • variables,=20 defining=20
  • verbose=20
  • version=20
  • version=20 script=20
  • version=20 script, symbol versions=20
  • VERSION=20 {script text}=20
  • versions=20 of symbols

    • w

  • warnings,=20 on combining symbols=20
  • warnings,=20 on section alignment=20
  • warnings,=20 on undefined symbols=20
  • = what is=20 this?

    • This document was generated on 7 November 1998 using the texi2html translator = version=20 1.52.