+@ifset GENERIC
+@item -rpath @var{dir}
+@cindex runtime library search path
+@kindex -rpath
+Add a directory to the runtime library search path. This is used when
+linking an ELF executable with shared objects. All @code{-rpath}
+arguments are concatenated and passed to the runtime linker, which uses
+them to locate shared objects at runtime. The @code{-rpath} option is
+also used when locating shared objects which are needed by shared
+objects explicitly included in the link; see the description of the
+@code{-rpath-link} option. If @code{-rpath} is not used when linking an
+ELF executable, the contents of the environment variable
+@code{LD_RUN_PATH} will be used if it is defined.
+
+The @code{-rpath} option may also be used on SunOS. By default, on
+SunOS, the linker will form a runtime search patch out of all the
+@code{-L} options it is given. If a @code{-rpath} option is used, the
+runtime search path will be formed exclusively using the @code{-rpath}
+options, ignoring the @code{-L} options. This can be useful when using
+gcc, which adds many @code{-L} options which may be on NFS mounted
+filesystems.
+
+For compatibility with other ELF linkers, if the @code{-R} option is
+followed by a directory name, rather than a file name, it is treated as
+the @code{-rpath} option.
+@end ifset
+
+@ifset GENERIC
+@cindex link-time runtime library search path
+@kindex -rpath-link
+@item -rpath-link @var{DIR}
+When using ELF or SunOS, one shared library may require another. This
+happens when an @code{ld -shared} link includes a shared library as one
+of the input files.
+
+When the linker encounters such a dependency when doing a non-shared,
+non-relocatable link, it will automatically try to locate the required
+shared library and include it in the link, if it is not included
+explicitly. In such a case, the @code{-rpath-link} option
+specifies the first set of directories to search. The
+@code{-rpath-link} option may specify a sequence of directory names
+either by specifying a list of names separated by colons, or by
+appearing multiple times.
+
+The linker uses the following search paths to locate required shared
+libraries.
+@enumerate
+@item
+Any directories specified by @code{-rpath-link} options.
+@item
+Any directories specified by @code{-rpath} options. The difference
+between @code{-rpath} and @code{-rpath-link} is that directories
+specified by @code{-rpath} options are included in the executable and
+used at runtime, whereas the @code{-rpath-link} option is only effective
+at link time.
+@item
+On an ELF system, if the @code{-rpath} and @code{rpath-link} options
+were not used, search the contents of the environment variable
+@code{LD_RUN_PATH}.
+@item
+On SunOS, if the @code{-rpath} option was not used, search any
+directories specified using @code{-L} options.
+@item
+For a native linker, the contents of the environment variable
+@code{LD_LIBRARY_PATH}.
+@item
+The default directories, normally @file{/lib} and @file{/usr/lib}.
+@item
+For a native linker on an ELF system, if the file @file{/etc/ld.so.conf}
+exists, the list of directories found in that file.
+@end enumerate
+
+If the required shared library is not found, the linker will issue a
+warning and continue with the link.
+@end ifset
+
+@kindex -shared
+@kindex -Bshareable
+@item -shared
+@itemx -Bshareable
+@cindex shared libraries
+Create a shared library. This is currently only supported on ELF, XCOFF
+and SunOS platforms. On SunOS, the linker will automatically create a
+shared library if the @code{-e} option is not used and there are
+undefined symbols in the link.
+
+@item --sort-common
+@kindex --sort-common
+This option tells @code{ld} to sort the common symbols by size when it
+places them in the appropriate output sections. First come all the one
+byte symbols, then all the two bytes, then all the four bytes, and then
+everything else. This is to prevent gaps between symbols due to
+alignment constraints.
+
+@kindex --split-by-file
+@item --split-by-file
+Similar to @code{--split-by-reloc} but creates a new output section for
+each input file.
+
+@kindex --split-by-reloc
+@item --split-by-reloc @var{count}
+Trys to creates extra sections in the output file so that no single
+output section in the file contains more than @var{count} relocations.
+This is useful when generating huge relocatable for downloading into
+certain real time kernels with the COFF object file format; since COFF
+cannot represent more than 65535 relocations in a single section. Note
+that this will fail to work with object file formats which do not
+support arbitrary sections. The linker will not split up individual
+input sections for redistribution, so if a single input section contains
+more than @var{count} relocations one output section will contain that
+many relocations.
+
+@kindex --stats
+@item --stats
+Compute and display statistics about the operation of the linker, such
+as execution time and memory usage.
+
+@kindex --traditional-format
+@cindex traditional format
+@item --traditional-format
+For some targets, the output of @code{ld} is different in some ways from
+the output of some existing linker. This switch requests @code{ld} to
+use the traditional format instead.
+
+@cindex dbx
+For example, on SunOS, @code{ld} combines duplicate entries in the
+symbol string table. This can reduce the size of an output file with
+full debugging information by over 30 percent. Unfortunately, the SunOS
+@code{dbx} program can not read the resulting program (@code{gdb} has no
+trouble). The @samp{--traditional-format} switch tells @code{ld} to not
+combine duplicate entries.
+
+@kindex -Tbss @var{org}
+@kindex -Tdata @var{org}
+@kindex -Ttext @var{org}
+@cindex segment origins, cmd line
+@item -Tbss @var{org}
+@itemx -Tdata @var{org}
+@itemx -Ttext @var{org}
+Use @var{org} as the starting address for---respectively---the
+@code{bss}, @code{data}, or the @code{text} segment of the output file.
+@var{org} must be a single hexadecimal integer;
+for compatibility with other linkers, you may omit the leading
+@samp{0x} usually associated with hexadecimal values.
+
+@kindex --verbose
+@cindex verbose
+@item --dll-verbose
+@itemx --verbose
+Display the version number for @code{ld} and list the linker emulations
+supported. Display which input files can and cannot be opened. Display
+the linker script if using a default builtin script.
+
+@kindex --version-script=@var{version-scriptfile}
+@cindex version script, symbol versions
+@itemx --version-script=@var{version-scriptfile}
+Specify the name of a version script to the linker. This is typically
+used when creating shared libraries to specify additional information
+about the version heirarchy for the library being created. This option
+is only meaningful on ELF platforms which support shared libraries.
+@xref{VERSION}.
+
+@kindex --warn-comon
+@cindex warnings, on combining symbols
+@cindex combining symbols, warnings on
+@item --warn-common
+Warn when a common symbol is combined with another common symbol or with
+a symbol definition. Unix linkers allow this somewhat sloppy practice,
+but linkers on some other operating systems do not. This option allows
+you to find potential problems from combining global symbols.
+Unfortunately, some C libraries use this practice, so you may get some
+warnings about symbols in the libraries as well as in your programs.
+
+There are three kinds of global symbols, illustrated here by C examples:
+
+@table @samp
+@item int i = 1;
+A definition, which goes in the initialized data section of the output
+file.
+
+@item extern int i;
+An undefined reference, which does not allocate space.
+There must be either a definition or a common symbol for the
+variable somewhere.
+
+@item int i;
+A common symbol. If there are only (one or more) common symbols for a
+variable, it goes in the uninitialized data area of the output file.
+The linker merges multiple common symbols for the same variable into a
+single symbol. If they are of different sizes, it picks the largest
+size. The linker turns a common symbol into a declaration, if there is
+a definition of the same variable.
+@end table
+
+The @samp{--warn-common} option can produce five kinds of warnings.
+Each warning consists of a pair of lines: the first describes the symbol
+just encountered, and the second describes the previous symbol
+encountered with the same name. One or both of the two symbols will be
+a common symbol.
+
+@enumerate
+@item
+Turning a common symbol into a reference, because there is already a
+definition for the symbol.
+@smallexample
+@var{file}(@var{section}): warning: common of `@var{symbol}'
+ overridden by definition
+@var{file}(@var{section}): warning: defined here
+@end smallexample
+
+@item
+Turning a common symbol into a reference, because a later definition for
+the symbol is encountered. This is the same as the previous case,
+except that the symbols are encountered in a different order.
+@smallexample
+@var{file}(@var{section}): warning: definition of `@var{symbol}'
+ overriding common
+@var{file}(@var{section}): warning: common is here
+@end smallexample
+
+@item
+Merging a common symbol with a previous same-sized common symbol.
+@smallexample
+@var{file}(@var{section}): warning: multiple common
+ of `@var{symbol}'
+@var{file}(@var{section}): warning: previous common is here
+@end smallexample
+
+@item
+Merging a common symbol with a previous larger common symbol.
+@smallexample
+@var{file}(@var{section}): warning: common of `@var{symbol}'
+ overridden by larger common
+@var{file}(@var{section}): warning: larger common is here
+@end smallexample
+
+@item
+Merging a common symbol with a previous smaller common symbol. This is
+the same as the previous case, except that the symbols are
+encountered in a different order.
+@smallexample
+@var{file}(@var{section}): warning: common of `@var{symbol}'
+ overriding smaller common
+@var{file}(@var{section}): warning: smaller common is here
+@end smallexample
+@end enumerate
+
+@kindex --warn-constructors
+@item --warn-constructors
+Warn if any global constructors are used. This is only useful for a few
+object file formats. For formats like COFF or ELF, the linker can not
+detect the use of global constructors.
+
+@kindex --warn-multiple-gp
+@item --warn-multiple-gp
+Warn if multiple global pointer values are required in the output file.
+This is only meaningful for certain processors, such as the Alpha.
+Specifically, some processors put large-valued constants in a special
+section. A special register (the global pointer) points into the middle
+of this section, so that constants can be loaded efficiently via a
+base-register relative addressing mode. Since the offset in
+base-register relative mode is fixed and relatively small (e.g., 16
+bits), this limits the maximum size of the constant pool. Thus, in
+large programs, it is often necessary to use multiple global pointer
+values in order to be able to address all possible constants. This
+option causes a warning to be issued whenever this case occurs.
+
+@kindex --warn-once
+@cindex warnings, on undefined symbols
+@cindex undefined symbols, warnings on
+@item --warn-once
+Only warn once for each undefined symbol, rather than once per module
+which refers to it.
+
+@kindex --warn-section-align
+@cindex warnings, on section alignment
+@cindex section alignment, warnings on
+@item --warn-section-align
+Warn if the address of an output section is changed because of
+alignment. Typically, the alignment will be set by an input section.
+The address will only be changed if it not explicitly specified; that
+is, if the @code{SECTIONS} command does not specify a start address for
+the section (@pxref{SECTIONS}).
+
+@kindex --whole-archive
+@cindex including an entire archive
+@item --whole-archive
+For each archive mentioned on the command line after the
+@code{--whole-archive} option, include every object file in the archive
+in the link, rather than searching the archive for the required object
+files. This is normally used to turn an archive file into a shared
+library, forcing every object to be included in the resulting shared
+library. This option may be used more than once.
+
+@kindex --wrap
+@item --wrap @var{symbol}
+Use a wrapper function for @var{symbol}. Any undefined reference to
+@var{symbol} will be resolved to @code{__wrap_@var{symbol}}. Any
+undefined reference to @code{__real_@var{symbol}} will be resolved to
+@var{symbol}.
+
+This can be used to provide a wrapper for a system function. The
+wrapper function should be called @code{__wrap_@var{symbol}}. If it
+wishes to call the system function, it should call
+@code{__real_@var{symbol}}.
+
+Here is a trivial example:
+
+@smallexample
+void *
+__wrap_malloc (int c)
+@{
+ printf ("malloc called with %ld\n", c);
+ return __real_malloc (c);
+@}
+@end smallexample
+
+If you link other code with this file using @code{--wrap malloc}, then
+all calls to @code{malloc} will call the function @code{__wrap_malloc}
+instead. The call to @code{__real_malloc} in @code{__wrap_malloc} will
+call the real @code{malloc} function.
+
+You may wish to provide a @code{__real_malloc} function as well, so that
+links without the @code{--wrap} option will succeed. If you do this,
+you should not put the definition of @code{__real_malloc} in the same
+file as @code{__wrap_malloc}; if you do, the assembler may resolve the
+call before the linker has a chance to wrap it to @code{malloc}.
+
+@end table
+
+@subsection Options specific to i386 PE targets
+
+The i386 PE linker supports the @code{-shared} option, which causes
+the output to be a dynamically linked library (DLL) instead of a
+normal executable. You should name the output @code{*.dll} when you
+use this option. In addition, the linker fully supports the standard
+@code{*.def} files, which may be specified on the linker command line
+like an object file (in fact, it should precede archives it exports
+symbols from, to ensure that they get linked in, just like a normal
+object file).
+
+In addition to the options common to all targets, the i386 PE linker
+support additional command line options that are specific to the i386
+PE target. Options that take values may be separated from their
+values by either a space or an equals sign.
+
+@table @code
+
+@kindex --add-stdcall-alias
+@item --add-stdcall-alias
+If given, symbols with a stdcall suffix (@@@var{nn}) will be exported
+as-is and also with the suffix stripped.
+
+@kindex --base-file
+@item --base-file @var{file}
+Use @var{file} as the name of a file in which to save the base
+addresses of all the relocations needed for generating DLLs with
+@file{dlltool}.
+
+@kindex --dll
+@item --dll
+Create a DLL instead of a regular executable. You may also use
+@code{-shared} or specify a @code{LIBRARY} in a given @code{.def}
+file.
+
+@kindex --enable-stdcall-fixup
+@kindex --disable-stdcall-fixup
+@item --enable-stdcall-fixup
+@itemx --disable-stdcall-fixup
+If the link finds a symbol that it cannot resolve, it will attempt to
+do "fuzzy linking" by looking for another defined symbol that differs
+only in the format of the symbol name (cdecl vs stdcall) and will
+resolve that symbol by linking to the match. For example, the
+undefined symbol @code{_foo} might be linked to the function
+@code{_foo@@12}, or the undefined symbol @code{_bar@@16} might be linked
+to the function @code{_bar}. When the linker does this, it prints a
+warning, since it normally should have failed to link, but sometimes
+import libraries generated from third-party dlls may need this feature
+to be usable. If you specify @code{--enable-stdcall-fixup}, this
+feature is fully enabled and warnings are not printed. If you specify
+@code{--disable-stdcall-fixup}, this feature is disabled and such
+mismatches are considered to be errors.
+
+@cindex DLLs, creating
+@kindex --export-all-symbols
+@item --export-all-symbols
+If given, all global symbols in the objects used to build a DLL will
+be exported by the DLL. Note that this is the default if there
+otherwise wouldn't be any exported symbols. When symbols are
+explicitly exported via DEF files or implicitly exported via function
+attributes, the default is to not export anything else unless this
+option is given. Note that the symbols @code{DllMain@@12},
+@code{DllEntryPoint@@0}, and @code{impure_ptr} will not be automatically
+exported.
+
+@kindex --exclude-symbols
+@item --exclude-symbols @var{symbol},@var{symbol},...
+Specifies a list of symbols which should not be automatically
+exported. The symbol names may be delimited by commas or colons.
+
+@kindex --file-alignment
+@item --file-alignment
+Specify the file alignment. Sections in the file will always begin at
+file offsets which are multiples of this number. This defaults to
+512.
+
+@cindex heap size
+@kindex --heap
+@item --heap @var{reserve}
+@itemx --heap @var{reserve},@var{commit}
+Specify the amount of memory to reserve (and optionally commit) to be
+used as heap for this program. The default is 1Mb reserved, 4K
+committed.
+
+@cindex image base
+@kindex --image-base
+@item --image-base @var{value}
+Use @var{value} as the base address of your program or dll. This is
+the lowest memory location that will be used when your program or dll
+is loaded. To reduce the need to relocate and improve performance of
+your dlls, each should have a unique base address and not overlap any
+other dlls. The default is 0x400000 for executables, and 0x10000000
+for dlls.
+
+@kindex --kill-at
+@item --kill-at
+If given, the stdcall suffixes (@@@var{nn}) will be stripped from
+symbols before they are exported.
+
+@kindex --major-image-version
+@item --major-image-version @var{value}
+Sets the major number of the "image version". Defaults to 1.
+
+@kindex --major-os-version
+@item --major-os-version @var{value}
+Sets the major number of the "os version". Defaults to 4.
+
+@kindex --major-subsystem-version
+@item --major-subsystem-version @var{value}
+Sets the major number of the "subsystem version". Defaults to 4.
+
+@kindex --minor-image-version
+@item --minor-image-version @var{value}
+Sets the minor number of the "image version". Defaults to 0.
+
+@kindex --minor-os-version
+@item --minor-os-version @var{value}
+Sets the minor number of the "os version". Defaults to 0.
+
+@kindex --minor-subsystem-version
+@item --minor-subsystem-version @var{value}
+Sets the minor number of the "subsystem version". Defaults to 0.
+
+@cindex DEF files, creating
+@cindex DLLs, creating
+@kindex --output-def
+@item --output-def @var{file}
+The linker will create the file @var{file} which will contain a DEF
+file corresponding to the DLL the linker is generating. This DEF file
+(which should be called @code{*.def}) may be used to create an import
+library with @code{dlltool} or may be used as a reference to
+automatically or implicitly exported symbols.
+
+@kindex --section-alignment
+@item --section-alignment
+Sets the section alignment. Sections in memory will always begin at
+addresses which are a multiple of this number. Defaults to 0x1000.
+
+@cindex stack size
+@kindex --stack
+@item --stack @var{reserve}
+@itemx --stack @var{reserve},@var{commit}
+Specify the amount of memory to reserve (and optionally commit) to be
+used as stack for this program. The default is 32Mb reserved, 4K
+committed.
+
+@kindex --subsystem
+@item --subsystem @var{which}
+@itemx --subsystem @var{which}:@var{major}
+@itemx --subsystem @var{which}:@var{major}.@var{minor}
+Specifies the subsystem under which your program will execute. The
+legal values for @var{which} are @code{native}, @code{windows},
+@code{console}, and @code{posix}. You may optionally set the
+subsystem version also.
+
+@end table
+
+@ifset UsesEnvVars
+@node Environment
+@section Environment Variables
+
+You can change the behavior of @code{ld} with the environment variables
+@code{GNUTARGET}, @code{LDEMULATION}, and @code{COLLECT_NO_DEMANGLE}.
+
+@kindex GNUTARGET
+@cindex default input format
+@code{GNUTARGET} determines the input-file object format if you don't
+use @samp{-b} (or its synonym @samp{--format}). Its value should be one
+of the BFD names for an input format (@pxref{BFD}). If there is no
+@code{GNUTARGET} in the environment, @code{ld} uses the natural format
+of the target. If @code{GNUTARGET} is set to @code{default} then BFD
+attempts to discover the input format by examining binary input files;
+this method often succeeds, but there are potential ambiguities, since
+there is no method of ensuring that the magic number used to specify
+object-file formats is unique. However, the configuration procedure for
+BFD on each system places the conventional format for that system first
+in the search-list, so ambiguities are resolved in favor of convention.
+
+@kindex LDEMULATION
+@cindex default emulation
+@cindex emulation, default
+@code{LDEMULATION} determines the default emulation if you don't use the
+@samp{-m} option. The emulation can affect various aspects of linker
+behaviour, particularly the default linker script. You can list the
+available emulations with the @samp{--verbose} or @samp{-V} options. If
+the @samp{-m} option is not used, and the @code{LDEMULATION} environment
+variable is not defined, the default emulation depends upon how the
+linker was configured.
+@end ifset
+
+@kindex COLLECT_NO_DEMANGLE
+@cindex demangling, default
+Normally, the linker will default to demangling symbols. However, if
+@code{COLLECT_NO_DEMANGLE} is set in the environment, then it will
+default to not demangling symbols. This environment variable is used in
+a similar fashion by the @code{gcc} linker wrapper program. The default
+may be overridden by the @samp{--demangle} and @samp{--no-demangle}
+options.
+
+@node Scripts
+@chapter Linker Scripts
+
+@cindex scripts
+@cindex linker scripts
+@cindex command files
+Every link is controlled by a @dfn{linker script}. This script is
+written in the linker command language.
+
+The main purpose of the linker script is to describe how the sections in
+the input files should be mapped into the output file, and to control
+the memory layout of the output file. Most linker scripts do nothing
+more than this. However, when necessary, the linker script can also
+direct the linker to perform many other operations, using the commands
+described below.
+
+The linker always uses a linker script. If you do not supply one
+yourself, the linker will use a default script that is compiled into the
+linker executable. You can use the @samp{--verbose} command line option
+to display the default linker script. Certain command line options,
+such as @samp{-r} or @samp{-N}, will affect the default linker script.
+
+You may supply your own linker script by using the @samp{-T} command
+line option. When you do this, your linker script will replace the
+default linker script.
+
+You may also use linker scripts implicitly by naming them as input files
+to the linker, as though they were files to be linked. @xref{Implicit
+Linker Scripts}.
+
+@menu
+* Basic Script Concepts:: Basic Linker Script Concepts
+* Script Format:: Linker Script Format
+* Simple Example:: Simple Linker Script Example
+* Simple Commands:: Simple Linker Script Commands
+* Assignments:: Assigning Values to Symbols
+* SECTIONS:: SECTIONS Command
+* MEMORY:: MEMORY Command
+* PHDRS:: PHDRS Command
+* VERSION:: VERSION Command
+* Expressions:: Expressions in Linker Scripts
+* Implicit Linker Scripts:: Implicit Linker Scripts
+@end menu
+
+@node Basic Script Concepts
+@section Basic Linker Script Concepts
+@cindex linker script concepts
+We need to define some basic concepts and vocabulary in order to
+describe the linker script language.
+
+The linker combines input files into a single output file. The output
+file and each input file are in a special data format known as an
+@dfn{object file format}. Each file is called an @dfn{object file}.
+The output file is often called an @dfn{executable}, but for our
+purposes we will also call it an object file. Each object file has,
+among other things, a list of @dfn{sections}. We sometimes refer to a
+section in an input file as an @dfn{input section}; similarly, a section
+in the output file is an @dfn{output section}.
+
+Each section in an object file has a name and a size. Most sections
+also have an associated block of data, known as the @dfn{section
+contents}. A section may be marked as @dfn{loadable}, which mean that
+the contents should be loaded into memory when the output file is run.
+A section with no contents may be @dfn{allocatable}, which means that an
+area in memory should be set aside, but nothing in particular should be
+loaded there (in some cases this memory must be zeroed out). A section
+which is neither loadable nor allocatable typically contains some sort
+of debugging information.
+
+Every loadable or allocatable output section has two addresses. The
+first is the @dfn{VMA}, or virtual memory address. This is the address
+the section will have when the output file is run. The second is the
+@dfn{LMA}, or load memory address. This is the address at which the
+section will be loaded. In most cases the two addresses will be the
+same. An example of when they might be different is when a data section
+is loaded into ROM, and then copied into RAM when the program starts up
+(this technique is often used to initialize global variables in a ROM
+based system). In this case the ROM address would be the LMA, and the
+RAM address would be the VMA.
+
+You can see the sections in an object file by using the @code{objdump}
+program with the @samp{-h} option.
+
+Every object file also has a list of @dfn{symbols}, known as the
+@dfn{symbol table}. A symbol may be defined or undefined. Each symbol
+has a name, and each defined symbol has an address, among other
+information. If you compile a C or C++ program into an object file, you
+will get a defined symbol for every defined function and global or
+static variable. Every undefined function or global variable which is
+referenced in the input file will become an undefined symbol.
+
+You can see the symbols in an object file by using the @code{nm}
+program, or by using the @code{objdump} program with the @samp{-t}
+option.
+
+@node Script Format
+@section Linker Script Format
+@cindex linker script format
+Linker scripts are text files.
+
+You write a linker script as a series of commands. Each command is
+either a keyword, possibly followed by arguments, or an assignment to a
+symbol. You may separate commands using semicolons. Whitespace is
+generally ignored.
+
+Strings such as file or format names can normally be entered directly.
+If the file name contains a character such as a comma which would
+otherwise serve to separate file names, you may put the file name in
+double quotes. There is no way to use a double quote character in a
+file name.
+
+You may include comments in linker scripts just as in C, delimited by
+@samp{/*} and @samp{*/}. As in C, comments are syntactically equivalent
+to whitespace.
+
+@node Simple Example
+@section Simple Linker Script Example
+@cindex linker script example
+@cindex example of linker script
+Many linker scripts are fairly simple.
+
+The simplest possible linker script has just one command:
+@samp{SECTIONS}. You use the @samp{SECTIONS} command to describe the
+memory layout of the output file.
+
+The @samp{SECTIONS} command is a powerful command. Here we will
+describe a simple use of it. Let's assume your program consists only of
+code, initialized data, and uninitialized data. These will be in the
+@samp{.text}, @samp{.data}, and @samp{.bss} sections, respectively.
+Let's assume further that these are the only sections which appear in
+your input files.
+
+For this example, let's say that the code should be loaded at address
+0x10000, and that the data should start at address 0x8000000. Here is a
+linker script which will do that:
+@smallexample
+SECTIONS
+@{
+ . = 0x10000;
+ .text : @{ *(.text) @}
+ . = 0x8000000;
+ .data : @{ *(.data) @}
+ .bss : @{ *(.bss) @}
+@}
+@end smallexample
+
+You write the @samp{SECTIONS} command as the keyword @samp{SECTIONS},
+followed by a series of symbol assignments and output section
+descriptions enclosed in curly braces.
+
+The first line in the above example sets the special symbol @samp{.},
+which is the location counter. If you do not specify the address of an
+output section in some other way (other ways are described later), the
+address is set from the current value of the location counter. The
+location counter is then incremented by the size of the output section.
+
+The first line inside the @samp{SECTIONS} command of the above example
+sets the value of the special symbol @samp{.}, which is the location
+counter. If you do not specify the address of an output section in some
+other way (other ways are described later), the address is set from the
+current value of the location counter. The location counter is then
+incremented by the size of the output section. At the start of the
+@samp{SECTIONS} command, the location counter has the value @samp{0}.
+
+The second line defines an output section, @samp{.text}. The colon is
+required syntax which may be ignored for now. Within the curly braces
+after the output section name, you list the names of the input sections
+which should be placed into this output section. The @samp{*} is a
+wildcard which matches any file name. The expression @samp{*(.text)}
+means all @samp{.text} input sections in all input files.
+
+Since the location counter is @samp{0x10000} when the output section
+@samp{.text} is defined, the linker will set the address of the
+@samp{.text} section in the output file to be @samp{0x10000}.
+
+The remaining lines define the @samp{.data} and @samp{.bss} sections in
+the output file. The linker will place the @samp{.data} output section
+at address @samp{0x8000000}. After the linker places the @samp{.data}
+output section, the value of the location counter will be
+@samp{0x8000000} plus the size of the @samp{.data} output section. The
+effect is that the linker will place the @samp{.bss} output section
+immediately after the @samp{.data} output section in memory
+
+The linker will ensure that each output section has the required
+alignment, by increasing the location counter if necessary. In this
+example, the specified addresses for the @samp{.text} and @samp{.data}
+sections will probably satisfy any alignment constraints, but the linker
+may have to create a small gap between the @samp{.data} and @samp{.bss}
+sections.
+
+That's it! That's a simple and complete linker script.
+
+@node Simple Commands
+@section Simple Linker Script Commands
+@cindex linker script simple commands
+In this section we describe the simple linker script commands.
+
+@menu
+* Entry Point:: Setting the entry point
+* File Commands:: Commands dealing with files
+@ifclear SingleFormat
+* Format Commands:: Commands dealing with object file formats
+@end ifclear
+
+* Miscellaneous Commands:: Other linker script commands
+@end menu
+
+@node Entry Point
+@subsection Setting the entry point
+@kindex ENTRY(@var{symbol})
+@cindex start of execution
+@cindex first instruction
+@cindex entry point
+The first instruction to execute in a program is called the @dfn{entry
+point}. You can use the @code{ENTRY} linker script command to set the
+entry point. The argument is a symbol name:
+@smallexample
+ENTRY(@var{symbol})
+@end smallexample
+
+There are several ways to set the entry point. The linker will set the
+entry point by trying each of the following methods in order, and
+stopping when one of them succeeds:
+@itemize @bullet
+@item
+the @samp{-e} @var{entry} command-line option;
+@item
+the @code{ENTRY(@var{symbol})} command in a linker script;
+@item
+the value of the symbol @code{start}, if defined;
+@item
+the address of the first byte of the @samp{.text} section, if present;
+@item
+The address @code{0}.
+@end itemize
+
+@node File Commands
+@subsection Commands dealing with files
+@cindex linker script file commands
+Several linker script commands deal with files.
+
+@table @code
+@item INCLUDE @var{filename}
+@kindex INCLUDE @var{filename}
+@cindex including a linker script
+Include the linker script @var{filename} at this point. The file will
+be searched for in the current directory, and in any directory specified
+with the @code{-L} option. You can nest calls to @code{INCLUDE} up to
+10 levels deep.
+
+@item INPUT(@var{file}, @var{file}, @dots{})
+@itemx INPUT(@var{file} @var{file} @dots{})
+@kindex INPUT(@var{files})
+@cindex input files in linker scripts
+@cindex input object files in linker scripts
+@cindex linker script input object files
+The @code{INPUT} command directs the linker to include the named files
+in the link, as though they were named on the command line.
+
+For example, if you always want to include @file{subr.o} any time you do
+a link, but you can't be bothered to put it on every link command line,
+then you can put @samp{INPUT (subr.o)} in your linker script.
+
+In fact, if you like, you can list all of your input files in the linker
+script, and then invoke the linker with nothing but a @samp{-T} option.
+
+The linker will first try to open the file in the current directory. If
+it is not found, the linker will search through the archive library
+search path. See the description of @samp{-L} in @ref{Options,,Command
+Line Options}.
+
+If you use @samp{INPUT (-l@var{file})}, @code{ld} will transform the
+name to @code{lib@var{file}.a}, as with the command line argument
+@samp{-l}.
+
+When you use the @code{INPUT} command in an implicit linker script, the
+files will be included in the link at the point at which the linker
+script file is included. This can affect archive searching.
+
+@item GROUP(@var{file}, @var{file}, @dots{})
+@itemx GROUP(@var{file} @var{file} @dots{})
+@kindex GROUP(@var{files})
+@cindex grouping input files
+The @code{GROUP} command is like @code{INPUT}, except that the named
+files should all be archives, and they are searched repeatedly until no
+new undefined references are created. See the description of @samp{-(}
+in @ref{Options,,Command Line Options}.
+
+@item OUTPUT(@var{filename})
+@kindex OUTPUT(@var{filename})
+@cindex output file name in linker scripot
+The @code{OUTPUT} command names the output file. Using
+@code{OUTPUT(@var{filename})} in the linker script is exactly like using
+@samp{-o @var{filename}} on the command line (@pxref{Options,,Command
+Line Options}). If both are used, the command line option takes
+precedence.
+
+You can use the @code{OUTPUT} command to define a default name for the
+output file other than the usual default of @file{a.out}.
+
+@item SEARCH_DIR(@var{path})
+@kindex SEARCH_DIR(@var{path})
+@cindex library search path in linker script
+@cindex archive search path in linker script
+@cindex search path in linker script
+The @code{SEARCH_DIR} command adds @var{path} to the list of paths where
+@code{ld} looks for archive libraries. Using
+@code{SEARCH_DIR(@var{path})} is exactly like using @samp{-L @var{path}}
+on the command line (@pxref{Options,,Command Line Options}). If both
+are used, then the linker will search both paths. Paths specified using
+the command line option are searched first.
+
+@item STARTUP(@var{filename})
+@kindex STARTUP(@var{filename})
+@cindex first input file
+The @code{STARTUP} command is just like the @code{INPUT} command, except
+that @var{filename} will become the first input file to be linked, as
+though it were specified first on the command line. This may be useful
+when using a system in which the entry point is always the start of the
+first file.
+@end table
+
+@ifclear SingleFormat
+@node Format Commands
+@subsection Commands dealing with object file formats
+A couple of linker script commands deal with object file formats.
+
+@table @code
+@item OUTPUT_FORMAT(@var{bfdname})
+@itemx OUTPUT_FORMAT(@var{default}, @var{big}, @var{little})
+@kindex OUTPUT_FORMAT(@var{bfdname})
+@cindex output file format in linker script
+The @code{OUTPUT_FORMAT} command names the BFD format to use for the
+output file (@pxref{BFD}). Using @code{OUTPUT_FORMAT(@var{bfdname})} is
+exactly like using @samp{-oformat @var{bfdname}} on the command line
+(@pxref{Options,,Command Line Options}). If both are used, the command
+line option takes precedence.
+
+You can use @code{OUTPUT_FORMAT} with three arguments to use different
+formats based on the @samp{-EB} and @samp{-EL} command line options.
+This permits the linker script to set the output format based on the
+desired endianness.
+
+If neither @samp{-EB} nor @samp{-EL} are used, then the output format
+will be the first argument, @var{default}. If @samp{-EB} is used, the
+output format will be the second argument, @var{big}. If @samp{-EL} is
+used, the output format will be the third argument, @var{little}.
+
+For example, the default linker script for the MIPS ELF target uses this
+command:
+@smallexample
+OUTPUT_FORMAT(elf32-bigmips, elf32-bigmips, elf32-littlemips)
+@end smallexample
+This says that the default format for the output file is
+@samp{elf32-bigmips}, but if the user uses the @samp{-EL} command line
+option, the output file will be created in the @samp{elf32-littlemips}
+format.
+
+@item TARGET(@var{bfdname})
+@kindex TARGET(@var{bfdname})
+@cindex input file format in linker script
+The @code{TARGET} command names the BFD format to use when reading input
+files. It affects subsequent @code{INPUT} and @code{GROUP} commands.
+This command is like using @samp{-b @var{bfdname}} on the command line
+(@pxref{Options,,Command Line Options}). If the @code{TARGET} command
+is used but @code{OUTPUT_FORMAT} is not, then the last @code{TARGET}
+command is also used to set the format for the output file. @xref{BFD}.
+@end table
+@end ifclear
+
+@node Miscellaneous Commands
+@subsection Other linker script commands
+There are a few other linker scripts commands.
+
+@table @code
+@item ASSERT(@var{exp}, @var{message})
+@kindex ASSERT
+@cindex assertion in linker script
+Ensure that @var{exp} is non-zero. If it is zero, then exit the linker
+with an error code, and print @var{message}.
+
+@item EXTERN(@var{symbol} @var{symbol} @dots{})
+@kindex EXTERN
+@cindex undefined symbol in linker script
+Force @var{symbol} to be entered in the output file as an undefined
+symbol. Doing this may, for example, trigger linking of additional
+modules from standard libraries. You may list several @var{symbol}s for
+each @code{EXTERN}, and you may use @code{EXTERN} multiple times. This
+command has the same effect as the @samp{-u} command-line option.
+
+@item FORCE_COMMON_ALLOCATION
+@kindex FORCE_COMMON_ALLOCATION
+@cindex common allocation in linker script
+This command has the same effect as the @samp{-d} command-line option:
+to make @code{ld} assign space to common symbols even if a relocatable
+output file is specified (@samp{-r}).
+
+@item NOCROSSREFS(@var{section} @var{section} @dots{})
+@kindex NOCROSSREFS(@var{sections})
+@cindex cross references
+This command may be used to tell @code{ld} to issue an error about any
+references among certain output sections.
+
+In certain types of programs, particularly on embedded systems when
+using overlays, when one section is loaded into memory, another section
+will not be. Any direct references between the two sections would be
+errors. For example, it would be an error if code in one section called
+a function defined in the other section.
+
+The @code{NOCROSSREFS} command takes a list of output section names. If
+@code{ld} detects any cross references between the sections, it reports
+an error and returns a non-zero exit status. Note that the
+@code{NOCROSSREFS} command uses output section names, not input section
+names.
+
+@ifclear SingleFormat
+@item OUTPUT_ARCH(@var{bfdarch})
+@kindex OUTPUT_ARCH(@var{bfdarch})
+@cindex machine architecture
+@cindex architecture
+Specify a particular output machine architecture. The argument is one
+of the names used by the BFD library (@pxref{BFD}). You can see the
+architecture of an object file by using the @code{objdump} program with
+the @samp{-f} option.
+@end ifclear
+@end table
+
+@node Assignments
+@section Assigning Values to Symbols
+@cindex assignment in scripts
+@cindex symbol definition, scripts
+@cindex variables, defining
+You may assign a value to a symbol in a linker script. This will define
+the symbol as a global symbol.
+
+@menu
+* Simple Assignments:: Simple Assignments
+* PROVIDE:: PROVIDE
+@end menu
+
+@node Simple Assignments
+@subsection Simple Assignments
+
+You may assign to a symbol using any of the C assignment operators:
+
+@table @code
+@item @var{symbol} = @var{expression} ;
+@itemx @var{symbol} += @var{expression} ;
+@itemx @var{symbol} -= @var{expression} ;
+@itemx @var{symbol} *= @var{expression} ;
+@itemx @var{symbol} /= @var{expression} ;
+@itemx @var{symbol} <<= @var{expression} ;
+@itemx @var{symbol} >>= @var{expression} ;
+@itemx @var{symbol} &= @var{expression} ;
+@itemx @var{symbol} |= @var{expression} ;
+@end table
+
+The first case will define @var{symbol} to the value of
+@var{expression}. In the other cases, @var{symbol} must already be
+defined, and the value will be adjusted accordingly.
+
+The special symbol name @samp{.} indicates the location counter. You
+may only use this within a @code{SECTIONS} command.
+
+The semicolon after @var{expression} is required.
+
+Expressions are defined below; see @ref{Expressions}.
+
+You may write symbol assignments as commands in their own right, or as
+statements within a @code{SECTIONS} command, or as part of an output
+section description in a @code{SECTIONS} command.
+
+The section of the symbol will be set from the section of the
+expression; for more information, see @ref{Expression Section}.
+
+Here is an example showing the three different places that symbol
+assignments may be used:
+
+@smallexample
+floating_point = 0;
+SECTIONS
+@{
+ .text :
+ @{
+ *(.text)
+ _etext = .;
+ @}
+ _bdata = (. + 3) & ~ 4;
+ .data : @{ *(.data) @}
+@}
+@end smallexample
+@noindent
+In this example, the symbol @samp{floating_point} will be defined as
+zero. The symbol @samp{_etext} will be defined as the address following
+the last @samp{.text} input section. The symbol @samp{_bdata} will be
+defined as the address following the @samp{.text} output section aligned
+upward to a 4 byte boundary.
+
+@node PROVIDE
+@subsection PROVIDE
+@cindex PROVIDE
+In some cases, it is desirable for a linker script to define a symbol
+only if it is referenced and is not defined by any object included in
+the link. For example, traditional linkers defined the symbol
+@samp{etext}. However, ANSI C requires that the user be able to use
+@samp{etext} as a function name without encountering an error. The
+@code{PROVIDE} keyword may be used to define a symbol, such as
+@samp{etext}, only if it is referenced but not defined. The syntax is
+@code{PROVIDE(@var{symbol} = @var{expression})}.
+
+Here is an example of using @code{PROVIDE} to define @samp{etext}:
+@smallexample
+SECTIONS
+@{
+ .text :
+ @{
+ *(.text)
+ _etext = .;
+ PROVIDE(etext = .);
+ @}
+@}
+@end smallexample
+
+In this example, if the program defines @samp{_etext} (with a leading
+underscore), the linker will give a multiple definition error. If, on
+the other hand, the program defines @samp{etext} (with no leading
+underscore), the linker will silently use the definition in the program.
+If the program references @samp{etext} but does not define it, the
+linker will use the definition in the linker script.
+
+@node SECTIONS
+@section SECTIONS command
+@kindex SECTIONS
+The @code{SECTIONS} command tells the linker how to map input sections
+into output sections, and how to place the output sections in memory.
+
+The format of the @code{SECTIONS} command is:
+@smallexample
+SECTIONS
+@{
+ @var{sections-command}
+ @var{sections-command}
+ @dots{}
+@}
+@end smallexample
+
+Each @var{sections-command} may of be one of the following:
+
+@itemize @bullet
+@item
+an @code{ENTRY} command (@pxref{Entry Point,,Entry command})
+@item
+a symbol assignment (@pxref{Assignments})
+@item
+an output section description
+@item
+an overlay description
+@end itemize
+
+The @code{ENTRY} command and symbol assignments are permitted inside the
+@code{SECTIONS} command for convenience in using the location counter in
+those commands. This can also make the linker script easier to
+understand because you can use those commands at meaningful points in
+the layout of the output file.
+
+Output section descriptions and overlay descriptions are described
+below.
+
+If you do not use a @code{SECTIONS} command in your linker script, the
+linker will place each input section into an identically named output
+section in the order that the sections are first encountered in the
+input files. If all input sections are present in the first file, for
+example, the order of sections in the output file will match the order
+in the first input file. The first section will be at address zero.
+
+@menu
+* Output Section Description:: Output section description
+* Output Section Name:: Output section name
+* Output Section Address:: Output section address
+* Input Section:: Input section description
+* Output Section Data:: Output section data
+* Output Section Keywords:: Output section keywords
+* Output Section Discarding:: Output section discarding
+* Output Section Attributes:: Output section attributes
+* Overlay Description:: Overlay description
+@end menu
+
+@node Output Section Description
+@subsection Output section description
+The full description of an output section looks like this:
+@smallexample
+@group
+@var{section} [@var{address}] [(@var{type})] : [AT(@var{lma})]
+ @{
+ @var{output-section-command}
+ @var{output-section-command}
+ @dots{}
+ @} [>@var{region}] [:@var{phdr} :@var{phdr} @dots{}] [=@var{fillexp}]
+@end group
+@end smallexample
+
+Most output sections do not use most of the optional section attributes.
+
+The whitespace around @var{section} is required, so that the section
+name is unambiguous. The colon and the curly braces are also required.
+The line breaks and other white space are optional.
+
+Each @var{output-section-command} may be one of the following:
+
+@itemize @bullet
+@item
+a symbol assignment (@pxref{Assignments})
+@item
+an input section description (@pxref{Input Section})
+@item
+data values to include directly (@pxref{Output Section Data})
+@item
+a special output section keyword (@pxref{Output Section Keywords})
+@end itemize
+
+@node Output Section Name
+@subsection Output section name
+@cindex name, section
+@cindex section name
+The name of the output section is @var{section}. @var{section} must
+meet the constraints of your output format. In formats which only
+support a limited number of sections, such as @code{a.out}, the name
+must be one of the names supported by the format (@code{a.out}, for
+example, allows only @samp{.text}, @samp{.data} or @samp{.bss}). If the
+output format supports any number of sections, but with numbers and not
+names (as is the case for Oasys), the name should be supplied as a
+quoted numeric string. A section name may consist of any sequence of
+characters, but a name which contains any unusual characters such as
+commas must be quoted.
+
+The output section name @samp{/DISCARD/} is special; @ref{Output Section
+Discarding}.
+
+@node Output Section Address
+@subsection Output section address
+@cindex address, section
+@cindex section address
+The @var{address} is an expression for the VMA (the virtual memory
+address) of the output section. If you do not provide @var{address},
+the linker will set it based on @var{region} if present, or otherwise
+based on the current value of the location counter.
+
+If you provide @var{address}, the address of the output section will be
+set to precisely that. If you provide neither @var{address} nor
+@var{region}, then the address of the output section will be set to the
+current value of the location counter aligned to the alignment
+requirements of the output section. The alignment requirement of the
+output section is the strictest alignment of any input section contained
+within the output section.
+
+For example,
+@smallexample
+.text . : @{ *(.text) @}
+@end smallexample
+@noindent
+and
+@smallexample
+.text : @{ *(.text) @}
+@end smallexample
+@noindent
+are subtly different. The first will set the address of the
+@samp{.text} output section to the current value of the location
+counter. The second will set it to the current value of the location
+counter aligned to the strictest alignment of a @samp{.text} input
+section.
+
+The @var{address} may be an arbitrary expression; @ref{Expressions}.
+For example, if you want to align the section on a 0x10 byte boundary,
+so that the lowest four bits of the section address are zero, you could
+do something like this:
+@smallexample
+.text ALIGN(0x10) : @{ *(.text) @}
+@end smallexample
+@noindent
+This works because @code{ALIGN} returns the current location counter
+aligned upward to the specified value.
+
+Specifying @var{address} for a section will change the value of the
+location counter.
+
+@node Input Section
+@subsection Input section description
+@cindex input sections
+@cindex mapping input sections to output sections
+The most common output section command is an input section description.
+
+The input section description is the most basic linker script operation.
+You use output sections to tell the linker how to lay out your program
+in memory. You use input section descriptions to tell the linker how to
+map the input files into your memory layout.
+
+@menu
+* Input Section Basics:: Input section basics
+* Input Section Wildcards:: Input section wildcard patterns
+* Input Section Common:: Input section for common symbols
+* Input Section Keep:: Input section and garbage collection
+* Input Section Example:: Input section example
+@end menu
+
+@node Input Section Basics
+@subsubsection Input section basics
+@cindex input section basics
+An input section description consists of a file name optionally followed
+by a list of section names in parentheses.
+
+The file name and the section name may be wildcard patterns, which we
+describe further below (@pxref{Input Section Wildcards}).
+
+The most common input section description is to include all input
+sections with a particular name in the output section. For example, to
+include all input @samp{.text} sections, you would write:
+@smallexample
+*(.text)
+@end smallexample
+@noindent
+Here the @samp{*} is a wildcard which matches any file name. To exclude a file
+from matching the file name wildcard, EXCLUDE_FILE may be used to match all files
+except the one specified by EXCLUDE_FILE. For example:
+@smallexample
+(*(EXCLUDE_FILE (*crtend.o) .ctors))
+@end smallexample
+will cause all .ctors sections from all files except crtend.o to be included.
+
+There are two ways to include more than one section:
+@smallexample
+*(.text .rdata)
+*(.text) *(.rdata)
+@end smallexample
+@noindent
+The difference between these is the order in which the @samp{.text} and
+@samp{.rdata} input sections will appear in the output section. In the
+first example, they will be intermingled. In the second example, all
+@samp{.text} input sections will appear first, followed by all
+@samp{.rdata} input sections.
+
+You can specify a file name to include sections from a particular file.
+You would do this if one or more of your files contain special data that
+needs to be at a particular location in memory. For example:
+@smallexample
+data.o(.data)
+@end smallexample
+
+If you use a file name without a list of sections, then all sections in
+the input file will be included in the output section. This is not
+commonly done, but it may by useful on occasion. For example:
+@smallexample
+data.o
+@end smallexample
+
+When you use a file name which does not contain any wild card
+characters, the linker will first see if you also specified the file
+name on the linker command line or in an @code{INPUT} command. If you
+did not, the linker will attempt to open the file as an input file, as
+though it appeared on the command line. Note that this differs from an
+@code{INPUT} command, because the linker will not search for the file in
+the archive search path.
+
+@node Input Section Wildcards
+@subsubsection Input section wildcard patterns
+@cindex input section wildcards
+@cindex wildcard file name patterns
+@cindex file name wildcard patterns
+@cindex section name wildcard patterns
+In an input section description, either the file name or the section
+name or both may be wildcard patterns.
+
+The file name of @samp{*} seen in many examples is a simple wildcard
+pattern for the file name.
+
+The wildcard patterns are like those used by the Unix shell.
+
+@table @samp
+@item *
+matches any number of characters
+@item ?
+matches any single character
+@item [@var{chars}]
+matches a single instance of any of the @var{chars}; the @samp{-}
+character may be used to specify a range of characters, as in
+@samp{[a-z]} to match any lower case letter
+@item \
+quotes the following character
+@end table
+
+When a file name is matched with a wildcard, the wildcard characters
+will not match a @samp{/} character (used to separate directory names on
+Unix). A pattern consisting of a single @samp{*} character is an
+exception; it will always match any file name, whether it contains a
+@samp{/} or not. In a section name, the wildcard characters will match
+a @samp{/} character.
+
+File name wildcard patterns only match files which are explicitly
+specified on the command line or in an @code{INPUT} command. The linker
+does not search directories to expand wildcards.
+
+If a file name matches more than one wildcard pattern, or if a file name
+appears explicitly and is also matched by a wildcard pattern, the linker
+will use the first match in the linker script. For example, this
+sequence of input section descriptions is probably in error, because the
+@file{data.o} rule will not be used:
+@smallexample
+.data : @{ *(.data) @}
+.data1 : @{ data.o(.data) @}
+@end smallexample
+
+@cindex SORT
+Normally, the linker will place files and sections matched by wildcards
+in the order in which they are seen during the link. You can change
+this by using the @code{SORT} keyword, which appears before a wildcard
+pattern in parentheses (e.g., @code{SORT(.text*)}). When the
+@code{SORT} keyword is used, the linker will sort the files or sections
+into ascending order by name before placing them in the output file.
+
+If you ever get confused about where input sections are going, use the
+@samp{-M} linker option to generate a map file. The map file shows
+precisely how input sections are mapped to output sections.
+
+This example shows how wildcard patterns might be used to partition
+files. This linker script directs the linker to place all @samp{.text}
+sections in @samp{.text} and all @samp{.bss} sections in @samp{.bss}.
+The linker will place the @samp{.data} section from all files beginning
+with an upper case character in @samp{.DATA}; for all other files, the
+linker will place the @samp{.data} section in @samp{.data}.
+@smallexample
+@group
+SECTIONS @{
+ .text : @{ *(.text) @}
+ .DATA : @{ [A-Z]*(.data) @}
+ .data : @{ *(.data) @}
+ .bss : @{ *(.bss) @}
+@}
+@end group
+@end smallexample
+
+@node Input Section Common
+@subsubsection Input section for common symbols
+@cindex common symbol placement
+@cindex uninitialized data placement
+A special notation is needed for common symbols, because in many object
+file formats common symbols do not have a particular input section. The
+linker treats common symbols as though they are in an input section
+named @samp{COMMON}.
+
+You may use file names with the @samp{COMMON} section just as with any
+other input sections. You can use this to place common symbols from a
+particular input file in one section while common symbols from other
+input files are placed in another section.
+
+In most cases, common symbols in input files will be placed in the
+@samp{.bss} section in the output file. For example:
+@smallexample
+.bss @{ *(.bss) *(COMMON) @}
+@end smallexample
+
+@cindex scommon section
+@cindex small common symbols
+Some object file formats have more than one type of common symbol. For
+example, the MIPS ELF object file format distinguishes standard common
+symbols and small common symbols. In this case, the linker will use a
+different special section name for other types of common symbols. In
+the case of MIPS ELF, the linker uses @samp{COMMON} for standard common
+symbols and @samp{.scommon} for small common symbols. This permits you
+to map the different types of common symbols into memory at different
+locations.
+
+@cindex [COMMON]
+You will sometimes see @samp{[COMMON]} in old linker scripts. This
+notation is now considered obsolete. It is equivalent to
+@samp{*(COMMON)}.
+
+@node Input Section Keep
+@subsubsection Input section and garbage collection
+@cindex KEEP
+@cindex garbage collection
+When link-time garbage collection is in use (@samp{--gc-sections}),
+it is often useful to mark sections that should not be eliminated.
+This is accomplished by surrounding an input section's wildcard entry
+with @code{KEEP()}, as in @code{KEEP(*(.init))} or
+@code{KEEP(SORT(*)(.ctors))}.
+
+@node Input Section Example
+@subsubsection Input section example
+The following example is a complete linker script. It tells the linker
+to read all of the sections from file @file{all.o} and place them at the
+start of output section @samp{outputa} which starts at location
+@samp{0x10000}. All of section @samp{.input1} from file @file{foo.o}
+follows immediately, in the same output section. All of section
+@samp{.input2} from @file{foo.o} goes into output section
+@samp{outputb}, followed by section @samp{.input1} from @file{foo1.o}.
+All of the remaining @samp{.input1} and @samp{.input2} sections from any
+files are written to output section @samp{outputc}.
+
+@smallexample
+@group
+SECTIONS @{
+ outputa 0x10000 :
+ @{
+ all.o
+ foo.o (.input1)
+ @}
+ outputb :
+ @{
+ foo.o (.input2)
+ foo1.o (.input1)
+ @}
+ outputc :
+ @{
+ *(.input1)
+ *(.input2)
+ @}
+@}
+@end group
+@end smallexample
+
+@node Output Section Data
+@subsection Output section data
+@cindex data
+@cindex section data
+@cindex output section data
+@kindex BYTE(@var{expression})
+@kindex SHORT(@var{expression})
+@kindex LONG(@var{expression})
+@kindex QUAD(@var{expression})
+@kindex SQUAD(@var{expression})
+You can include explicit bytes of data in an output section by using
+@code{BYTE}, @code{SHORT}, @code{LONG}, @code{QUAD}, or @code{SQUAD} as
+an output section command. Each keyword is followed by an expression in
+parentheses providing the value to store (@pxref{Expressions}). The
+value of the expression is stored at the current value of the location
+counter.
+
+The @code{BYTE}, @code{SHORT}, @code{LONG}, and @code{QUAD} commands
+store one, two, four, and eight bytes (respectively). After storing the
+bytes, the location counter is incremented by the number of bytes
+stored.
+
+For example, this will store the byte 1 followed by the four byte value
+of the symbol @samp{addr}:
+@smallexample
+BYTE(1)
+LONG(addr)
+@end smallexample
+
+When using a 64 bit host or target, @code{QUAD} and @code{SQUAD} are the
+same; they both store an 8 byte, or 64 bit, value. When both host and
+target are 32 bits, an expression is computed as 32 bits. In this case
+@code{QUAD} stores a 32 bit value zero extended to 64 bits, and
+@code{SQUAD} stores a 32 bit value sign extended to 64 bits.
+
+If the object file format of the output file has an explicit endianness,
+which is the normal case, the value will be stored in that endianness.
+When the object file format does not have an explicit endianness, as is
+true of, for example, S-records, the value will be stored in the
+endianness of the first input object file.
+
+@kindex FILL(@var{expression})
+@cindex holes, filling
+@cindex unspecified memory
+You may use the @code{FILL} command to set the fill pattern for the
+current section. It is followed by an expression in parentheses. Any
+otherwise unspecified regions of memory within the section (for example,
+gaps left due to the required alignment of input sections) are filled
+with the two least significant bytes of the expression, repeated as
+necessary. A @code{FILL} statement covers memory locations after the
+point at which it occurs in the section definition; by including more
+than one @code{FILL} statement, you can have different fill patterns in
+different parts of an output section.
+
+This example shows how to fill unspecified regions of memory with the
+value @samp{0x9090}:
+@smallexample
+FILL(0x9090)
+@end smallexample
+
+The @code{FILL} command is similar to the @samp{=@var{fillexp}} output
+section attribute (@pxref{Output Section Fill}), but it only affects the
+part of the section following the @code{FILL} command, rather than the
+entire section. If both are used, the @code{FILL} command takes
+precedence.
+
+@node Output Section Keywords
+@subsection Output section keywords
+There are a couple of keywords which can appear as output section
+commands.
+
+@table @code
+@kindex CREATE_OBJECT_SYMBOLS
+@cindex input filename symbols
+@cindex filename symbols
+@item CREATE_OBJECT_SYMBOLS
+The command tells the linker to create a symbol for each input file.
+The name of each symbol will be the name of the corresponding input
+file. The section of each symbol will be the output section in which
+the @code{CREATE_OBJECT_SYMBOLS} command appears.
+
+This is conventional for the a.out object file format. It is not
+normally used for any other object file format.
+
+@kindex CONSTRUCTORS
+@cindex C++ constructors, arranging in link
+@cindex constructors, arranging in link
+@item CONSTRUCTORS
+When linking using the a.out object file format, the linker uses an
+unusual set construct to support C++ global constructors and
+destructors. When linking object file formats which do not support
+arbitrary sections, such as ECOFF and XCOFF, the linker will
+automatically recognize C++ global constructors and destructors by name.
+For these object file formats, the @code{CONSTRUCTORS} command tells the
+linker to place constructor information in the output section where the
+@code{CONSTRUCTORS} command appears. The @code{CONSTRUCTORS} command is
+ignored for other object file formats.
+
+The symbol @w{@code{__CTOR_LIST__}} marks the start of the global
+constructors, and the symbol @w{@code{__DTOR_LIST}} marks the end. The
+first word in the list is the number of entries, followed by the address
+of each constructor or destructor, followed by a zero word. The
+compiler must arrange to actually run the code. For these object file
+formats @sc{gnu} C++ normally calls constructors from a subroutine
+@code{__main}; a call to @code{__main} is automatically inserted into
+the startup code for @code{main}. @sc{gnu} C++ normally runs
+destructors either by using @code{atexit}, or directly from the function
+@code{exit}.
+
+For object file formats such as @code{COFF} or @code{ELF} which support
+arbitrary section names, @sc{gnu} C++ will normally arrange to put the
+addresses of global constructors and destructors into the @code{.ctors}
+and @code{.dtors} sections. Placing the following sequence into your
+linker script will build the sort of table which the @sc{gnu} C++
+runtime code expects to see.
+
+@smallexample
+ __CTOR_LIST__ = .;
+ LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
+ *(.ctors)
+ LONG(0)
+ __CTOR_END__ = .;
+ __DTOR_LIST__ = .;
+ LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
+ *(.dtors)
+ LONG(0)
+ __DTOR_END__ = .;
+@end smallexample
+
+If you are using the @sc{gnu} C++ support for initialization priority,
+which provides some control over the order in which global constructors
+are run, you must sort the constructors at link time to ensure that they
+are executed in the correct order. When using the @code{CONSTRUCTORS}
+command, use @samp{SORT(CONSTRUCTORS)} instead. When using the
+@code{.ctors} and @code{.dtors} sections, use @samp{*(SORT(.ctors))} and
+@samp{*(SORT(.dtors))} instead of just @samp{*(.ctors)} and
+@samp{*(.dtors)}.
+
+Normally the compiler and linker will handle these issues automatically,
+and you will not need to concern yourself with them. However, you may
+need to consider this if you are using C++ and writing your own linker
+scripts.
+
+@end table
+
+@node Output Section Discarding
+@subsection Output section discarding
+@cindex discarding sections
+@cindex sections, discarding
+@cindex removing sections
+The linker will not create output section which do not have any
+contents. This is for convenience when referring to input sections that
+may or may not be present in any of the input files. For example:
+@smallexample
+.foo @{ *(.foo) @}
+@end smallexample
+@noindent
+will only create a @samp{.foo} section in the output file if there is a
+@samp{.foo} section in at least one input file.
+
+If you use anything other than an input section description as an output
+section command, such as a symbol assignment, then the output section
+will always be created, even if there are no matching input sections.
+
+@cindex /DISCARD/
+The special output section name @samp{/DISCARD/} may be used to discard
+input sections. Any input sections which are assigned to an output
+section named @samp{/DISCARD/} are not included in the output file.
+
+@node Output Section Attributes
+@subsection Output section attributes
+@cindex output section attributes
+We showed above that the full description of an output section looked
+like this:
+@smallexample
+@group
+@var{section} [@var{address}] [(@var{type})] : [AT(@var{lma})]
+ @{
+ @var{output-section-command}
+ @var{output-section-command}
+ @dots{}
+ @} [>@var{region}] [:@var{phdr} :@var{phdr} @dots{}] [=@var{fillexp}]
+@end group
+@end smallexample
+We've already described @var{section}, @var{address}, and
+@var{output-section-command}. In this section we will describe the
+remaining section attributes.
+
+@menu
+* Output Section Type:: Output section type
+* Output Section LMA:: Output section LMA
+* Output Section Region:: Output section region
+* Output Section Phdr:: Output section phdr
+* Output Section Fill:: Output section fill
+@end menu
+
+@node Output Section Type
+@subsubsection Output section type
+Each output section may have a type. The type is a keyword in
+parentheses. The following types are defined:
+
+@table @code
+@item NOLOAD
+The section should be marked as not loadable, so that it will not be
+loaded into memory when the program is run.
+@item DSECT
+@itemx COPY
+@itemx INFO
+@itemx OVERLAY
+These type names are supported for backward compatibility, and are
+rarely used. They all have the same effect: the section should be
+marked as not allocatable, so that no memory is allocated for the
+section when the program is run.
+@end table
+
+@kindex NOLOAD
+@cindex prevent unnecessary loading
+@cindex loading, preventing
+The linker normally sets the attributes of an output section based on
+the input sections which map into it. You can override this by using
+the section type. For example, in the script sample below, the
+@samp{ROM} section is addressed at memory location @samp{0} and does not
+need to be loaded when the program is run. The contents of the
+@samp{ROM} section will appear in the linker output file as usual.
+@smallexample
+@group
+SECTIONS @{
+ ROM 0 (NOLOAD) : @{ @dots{} @}
+ @dots{}
+@}
+@end group
+@end smallexample
+
+@node Output Section LMA
+@subsubsection Output section LMA
+@kindex AT(@var{lma})
+@cindex load address
+@cindex section load address
+Every section has a virtual address (VMA) and a load address (LMA); see
+@ref{Basic Script Concepts}. The address expression which may appear in
+an output section description sets the VMA (@pxref{Output Section
+Address}).
+
+The linker will normally set the LMA equal to the VMA. You can change
+that by using the @code{AT} keyword. The expression @var{lma} that
+follows the @code{AT} keyword specifies the load address of the section.
+
+@cindex ROM initialized data
+@cindex initialized data in ROM
+This feature is designed to make it easy to build a ROM image. For
+example, the following linker script creates three output sections: one
+called @samp{.text}, which starts at @code{0x1000}, one called
+@samp{.mdata}, which is loaded at the end of the @samp{.text} section
+even though its VMA is @code{0x2000}, and one called @samp{.bss} to hold
+uninitialized data at address @code{0x3000}. The symbol @code{_data} is
+defined with the value @code{0x2000}, which shows that the location
+counter holds the VMA value, not the LMA value.
+
+@smallexample
+@group
+SECTIONS
+ @{
+ .text 0x1000 : @{ *(.text) _etext = . ; @}
+ .mdata 0x2000 :
+ AT ( ADDR (.text) + SIZEOF (.text) )
+ @{ _data = . ; *(.data); _edata = . ; @}
+ .bss 0x3000 :
+ @{ _bstart = . ; *(.bss) *(COMMON) ; _bend = . ;@}
+@}
+@end group
+@end smallexample
+
+The run-time initialization code for use with a program generated with
+this linker script would include something like the following, to copy
+the initialized data from the ROM image to its runtime address. Notice
+how this code takes advantage of the symbols defined by the linker
+script.
+
+@smallexample
+@group
+extern char _etext, _data, _edata, _bstart, _bend;
+char *src = &_etext;
+char *dst = &_data;
+
+/* ROM has data at end of text; copy it. */
+while (dst < &_edata) @{
+ *dst++ = *src++;
+@}
+
+/* Zero bss */
+for (dst = &_bstart; dst< &_bend; dst++)
+ *dst = 0;
+@end group
+@end smallexample
+
+@node Output Section Region
+@subsubsection Output section region
+@kindex >@var{region}
+@cindex section, assigning to memory region
+@cindex memory regions and sections
+You can assign a section to a previously defined region of memory by
+using @samp{>@var{region}}. @xref{MEMORY}.
+
+Here is a simple example:
+@smallexample
+@group
+MEMORY @{ rom : ORIGIN = 0x1000, LENGTH = 0x1000 @}
+SECTIONS @{ ROM : @{ *(.text) @} >rom @}
+@end group
+@end smallexample
+
+@node Output Section Phdr
+@subsubsection Output section phdr
+@kindex :@var{phdr}
+@cindex section, assigning to program header
+@cindex program headers and sections
+You can assign a section to a previously defined program segment by
+using @samp{:@var{phdr}}. @xref{PHDRS}. If a section is assigned to
+one or more segments, then all subsequent allocated sections will be
+assigned to those segments as well, unless they use an explicitly
+@code{:@var{phdr}} modifier. You can use @code{:NONE} to tell the
+linker to not put the section in any segment at all.
+
+Here is a simple example:
+@smallexample
+@group
+PHDRS @{ text PT_LOAD ; @}
+SECTIONS @{ .text : @{ *(.text) @} :text @}
+@end group
+@end smallexample
+
+@node Output Section Fill
+@subsubsection Output section fill
+@kindex =@var{fillexp}
+@cindex section fill pattern
+@cindex fill pattern, entire section
+You can set the fill pattern for an entire section by using
+@samp{=@var{fillexp}}. @var{fillexp} is an expression
+(@pxref{Expressions}). Any otherwise unspecified regions of memory
+within the output section (for example, gaps left due to the required
+alignment of input sections) will be filled with the two least
+significant bytes of the value, repeated as necessary.
+
+You can also change the fill value with a @code{FILL} command in the
+output section commands; see @ref{Output Section Data}.
+
+Here is a simple example:
+@smallexample
+@group
+SECTIONS @{ .text : @{ *(.text) @} =0x9090 @}
+@end group
+@end smallexample
+
+@node Overlay Description
+@subsection Overlay description
+@kindex OVERLAY
+@cindex overlays
+An overlay description provides an easy way to describe sections which
+are to be loaded as part of a single memory image but are to be run at
+the same memory address. At run time, some sort of overlay manager will
+copy the overlaid sections in and out of the runtime memory address as
+required, perhaps by simply manipulating addressing bits. This approach
+can be useful, for example, when a certain region of memory is faster
+than another.
+
+Overlays are described using the @code{OVERLAY} command. The
+@code{OVERLAY} command is used within a @code{SECTIONS} command, like an
+output section description. The full syntax of the @code{OVERLAY}
+command is as follows:
+@smallexample
+@group
+OVERLAY [@var{start}] : [NOCROSSREFS] [AT ( @var{ldaddr} )]
+ @{
+ @var{secname1}
+ @{
+ @var{output-section-command}
+ @var{output-section-command}
+ @dots{}
+ @} [:@var{phdr}@dots{}] [=@var{fill}]
+ @var{secname2}
+ @{
+ @var{output-section-command}
+ @var{output-section-command}
+ @dots{}
+ @} [:@var{phdr}@dots{}] [=@var{fill}]
+ @dots{}
+ @} [>@var{region}] [:@var{phdr}@dots{}] [=@var{fill}]
+@end group
+@end smallexample
+
+Everything is optional except @code{OVERLAY} (a keyword), and each
+section must have a name (@var{secname1} and @var{secname2} above). The
+section definitions within the @code{OVERLAY} construct are identical to
+those within the general @code{SECTIONS} contruct (@pxref{SECTIONS}),
+except that no addresses and no memory regions may be defined for
+sections within an @code{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 starting at the load address used for the @code{OVERLAY} as a
+whole (as with normal section definitions, the load address is optional,
+and defaults to the start address; the start address is also optional,
+and defaults to the current value of the location counter).
+
+If the @code{NOCROSSREFS} keyword is used, and there any references
+among the sections, the linker will report an error. Since the sections
+all run at the same address, it normally does not make sense for one
+section to refer directly to another. @xref{Miscellaneous Commands,
+NOCROSSREFS}.
+
+For each section within the @code{OVERLAY}, the linker automatically
+defines two symbols. The symbol @code{__load_start_@var{secname}} is
+defined as the starting load address of the section. The symbol
+@code{__load_stop_@var{secname}} is defined as the final load address of
+the section. Any characters within @var{secname} which are not legal
+within C identifiers are removed. C (or assembler) code may use these
+symbols to move the overlaid sections around as necessary.
+
+At the end of the overlay, the value of the location counter is set to
+the start address of the overlay plus the size of the largest section.
+
+Here is an example. Remember that this would appear inside a
+@code{SECTIONS} construct.
+@smallexample
+@group
+ OVERLAY 0x1000 : AT (0x4000)
+ @{
+ .text0 @{ o1/*.o(.text) @}
+ .text1 @{ o2/*.o(.text) @}
+ @}
+@end group
+@end smallexample
+@noindent
+This will define both @samp{.text0} and @samp{.text1} to start at
+address 0x1000. @samp{.text0} will be loaded at address 0x4000, and
+@samp{.text1} will be loaded immediately after @samp{.text0}. The
+following symbols will be defined: @code{__load_start_text0},
+@code{__load_stop_text0}, @code{__load_start_text1},
+@code{__load_stop_text1}.
+
+C code to copy overlay @code{.text1} into the overlay area might look
+like the following.
+
+@smallexample
+@group
+ extern char __load_start_text1, __load_stop_text1;
+ memcpy ((char *) 0x1000, &__load_start_text1,
+ &__load_stop_text1 - &__load_start_text1);
+@end group
+@end smallexample
+
+Note that the @code{OVERLAY} command is just syntactic sugar, since
+everything it does can be done using the more basic commands. The above
+example could have been written identically as follows.
+
+@smallexample
+@group
+ .text0 0x1000 : AT (0x4000) @{ o1/*.o(.text) @}
+ __load_start_text0 = LOADADDR (.text0);
+ __load_stop_text0 = LOADADDR (.text0) + SIZEOF (.text0);
+ .text1 0x1000 : AT (0x4000 + SIZEOF (.text0)) @{ o2/*.o(.text) @}
+ __load_start_text1 = LOADADDR (.text1);
+ __load_stop_text1 = LOADADDR (.text1) + SIZEOF (.text1);
+ . = 0x1000 + MAX (SIZEOF (.text0), SIZEOF (.text1));
+@end group
+@end smallexample
+
+@node MEMORY
+@section MEMORY command
+@kindex MEMORY
+@cindex memory regions
+@cindex regions of memory
+@cindex allocating memory
+@cindex discontinuous memory
+The linker's default configuration permits allocation of all available
+memory. You can override this by using the @code{MEMORY} command.
+
+The @code{MEMORY} command describes the location and size of blocks of
+memory in the target. You can use it to describe which memory regions
+may be used by the linker, and which memory regions it must avoid. You
+can then assign sections to particular memory regions. The linker will
+set section addresses based on the memory regions, and will warn about
+regions that become too full. The linker will not shuffle sections
+around to fit into the available regions.
+
+A linker script may contain at most one use of the @code{MEMORY}
+command. However, you can define as many blocks of memory within it as
+you wish. The syntax is:
+@smallexample
+@group
+MEMORY
+ @{
+ @var{name} [(@var{attr})] : ORIGIN = @var{origin}, LENGTH = @var{len}
+ @dots{}
+ @}
+@end group
+@end smallexample
+
+The @var{name} is a name used in the linker script to refer to the
+region. The region name has no meaning outside of the linker script.
+Region names are stored in a separate name space, and will not conflict
+with symbol names, file names, or section names. Each memory region
+must have a distinct name.
+
+@cindex memory region attributes
+The @var{attr} string is an optional list of attributes that specify
+whether to use a particular memory region for an input section which is
+not explicitly mapped in the linker script. As described in
+@ref{SECTIONS}, if you do not specify an output section for some input
+section, the linker will create an output section with the same name as
+the input section. If you define region attributes, the linker will use
+them to select the memory region for the output section that it creates.
+
+The @var{attr} string must consist only of the following characters:
+@table @samp
+@item R
+Read-only section
+@item W
+Read/write section
+@item X
+Executable section
+@item A
+Allocatable section
+@item I
+Initialized section
+@item L
+Same as @samp{I}
+@item !
+Invert the sense of any of the preceding attributes
+@end table
+
+If a unmapped section matches any of the listed attributes other than
+@samp{!}, it will be placed in the memory region. The @samp{!}
+attribute reverses this test, so that an unmapped section will be placed
+in the memory region only if it does not match any of the listed
+attributes.
+
+@kindex ORIGIN =
+@kindex o =
+@kindex org =
+The @var{origin} is an expression for the start address of the memory
+region. The expression must evaluate to a constant before memory
+allocation is performed, which means that you may not use any section
+relative symbols. The keyword @code{ORIGIN} may be abbreviated to
+@code{org} or @code{o} (but not, for example, @code{ORG}).
+
+@kindex LENGTH =
+@kindex len =
+@kindex l =
+The @var{len} is an expression for the size in bytes of the memory
+region. As with the @var{origin} expression, the expression must
+evaluate to a constant before memory allocation is performed. The
+keyword @code{LENGTH} may be abbreviated to @code{len} or @code{l}.
+
+In the following example, we specify that there are two memory regions
+available for allocation: one starting at @samp{0} for 256 kilobytes,
+and the other starting at @samp{0x40000000} for four megabytes. The
+linker will place into the @samp{rom} memory region every section which
+is not explicitly mapped into a memory region, and is either read-only
+or executable. The linker will place other sections which are not
+explicitly mapped into a memory region into the @samp{ram} memory
+region.
+
+@smallexample
+@group
+MEMORY
+ @{
+ rom (rx) : ORIGIN = 0, LENGTH = 256K
+ ram (!rx) : org = 0x40000000, l = 4M
+ @}
+@end group
+@end smallexample
+
+Once you define a memory region, you can direct the linker to place
+specific output sections into that memory region by using the
+@samp{>@var{region}} output section attribute. For example, if you have
+a memory region named @samp{mem}, you would use @samp{>mem} in the
+output section definition. @xref{Output Section Region}. If no address
+was specified for the output section, the linker will set the address to
+the next available address within the memory region. If the combined
+output sections directed to a memory region are too large for the
+region, the linker will issue an error message.
+
+@node PHDRS
+@section PHDRS Command
+@kindex PHDRS
+@cindex program headers
+@cindex ELF program headers
+@cindex program segments
+@cindex segments, ELF
+The ELF object file format uses @dfn{program headers}, also knows as
+@dfn{segments}. The program headers describe how the program should be
+loaded into memory. You can print them out by using the @code{objdump}
+program with the @samp{-p} option.
+
+When you run an ELF program on a native ELF system, the system loader
+reads the program headers in order to figure out how to load the
+program. This will only work if the program headers are set correctly.
+This manual does not describe the details of how the system loader
+interprets program headers; for more information, see the ELF ABI.
+
+The linker will create reasonable program headers by default. However,
+in some cases, you may need to specify the program headers more
+precisely. You may use the @code{PHDRS} command for this purpose. When
+the linker sees the @code{PHDRS} command in the linker script, it will
+not create any program headers other than the ones specified.
+
+The linker only pays attention to the @code{PHDRS} command when
+generating an ELF output file. In other cases, the linker will simply
+ignore @code{PHDRS}.
+
+This is the syntax of the @code{PHDRS} command. The words @code{PHDRS},
+@code{FILEHDR}, @code{AT}, and @code{FLAGS} are keywords.
+
+@smallexample
+@group
+PHDRS
+@{
+ @var{name} @var{type} [ FILEHDR ] [ PHDRS ] [ AT ( @var{address} ) ]
+ [ FLAGS ( @var{flags} ) ] ;
+@}
+@end group
+@end smallexample
+
+The @var{name} is used only for reference in the @code{SECTIONS} command
+of the linker script. It is not put into the output file. Program
+header names are stored in a separate name space, and will not conflict
+with symbol names, file names, or section names. Each program header
+must have a distinct name.
+
+Certain program header types describe segments of memory which the
+system loader will load from the file. In the linker script, you
+specify the contents of these segments by placing allocatable output
+sections in the segments. You use the @samp{:@var{phdr}} output section
+attribute to place a section in a particular segment. @xref{Output
+Section Phdr}.
+
+It is normal to put certain sections in more than one segment. This
+merely implies that one segment of memory contains another. You may
+repeat @samp{:@var{phdr}}, using it once for each segment which should
+contain the section.
+
+If you place a section in one or more segments using @samp{:@var{phdr}},
+then the linker will place all subsequent allocatable sections which do
+not specify @samp{:@var{phdr}} in the same segments. This is for
+convenience, since generally a whole set of contiguous sections will be
+placed in a single segment. You can use @code{:NONE} to override the
+default segment and tell the linker to not put the section in any
+segment at all.
+
+@kindex FILEHDR
+@kindex PHDRS
+You may use the @code{FILEHDR} and @code{PHDRS} keywords appear after
+the program header type to further describe the contents of the segment.
+The @code{FILEHDR} keyword means that the segment should include the ELF
+file header. The @code{PHDRS} keyword means that the segment should
+include the ELF program headers themselves.
+
+The @var{type} may be one of the following. The numbers indicate the
+value of the keyword.
+
+@table @asis
+@item @code{PT_NULL} (0)
+Indicates an unused program header.
+
+@item @code{PT_LOAD} (1)
+Indicates that this program header describes a segment to be loaded from
+the file.
+
+@item @code{PT_DYNAMIC} (2)
+Indicates a segment where dynamic linking information can be found.
+
+@item @code{PT_INTERP} (3)
+Indicates a segment where the name of the program interpreter may be
+found.
+
+@item @code{PT_NOTE} (4)
+Indicates a segment holding note information.
+
+@item @code{PT_SHLIB} (5)
+A reserved program header type, defined but not specified by the ELF
+ABI.
+
+@item @code{PT_PHDR} (6)
+Indicates a segment where the program headers may be found.
+
+@item @var{expression}
+An expression giving the numeric type of the program header. This may
+be used for types not defined above.
+@end table
+
+You can specify that a segment should be loaded at a particular address
+in memory by using an @code{AT} expression. This is identical to the
+@code{AT} command used as an output section attribute (@pxref{Output
+Section LMA}). The @code{AT} command for a program header overrides the
+output section attribute.
+
+The linker will normally set the segment flags based on the sections
+which comprise the segment. You may use the @code{FLAGS} keyword to
+explicitly specify the segment flags. The value of @var{flags} must be
+an integer. It is used to set the @code{p_flags} field of the program
+header.
+
+Here is an example of @code{PHDRS}. This shows a typical set of program
+headers used on a native ELF system.