\input texinfo
@setfilename ld.info
@c Copyright 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-@c 2001, 2002, 2003, 2004 Free Software Foundation, Inc.
+@c 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
@syncodeindex ky cp
@include configdoc.texi
@c (configdoc.texi is generated by the Makefile)
@samp{0} for base 8). @xref{Entry Point}, for a discussion of defaults
and other ways of specifying the entry point.
+@kindex --exclude-libs
+@item --exclude-libs @var{lib},@var{lib},...
+Specifies a list of archive libraries from which symbols should not be automatically
+exported. The library names may be delimited by commas or colons. Specifying
+@code{--exclude-libs ALL} excludes symbols in all archive libraries from
+automatic export. This option is available only for the i386 PE targeted
+port of the linker and for ELF targeted ports. For i386 PE, symbols
+explicitly listed in a .def file are still exported, regardless of this
+option. For ELF targeted ports, symbols affected by this option will
+be treated as hidden.
+
@cindex dynamic symbol table
@kindex -E
@kindex --export-dynamic
on the command line after the @option{--as-needed} option. Normally,
the linker will add a DT_NEEDED tag for each dynamic library mentioned
on the command line, regardless of whether the library is actually
-needed. @option{--as-needed} causes DT_NEEDED tags to only be emitted
-for libraries that satisfy some reference from regular objects.
+needed. @option{--as-needed} causes DT_NEEDED tags to only be emitted
+for libraries that satisfy some symbol reference from regular objects
+which is undefined at the point that the library was linked.
@option{--no-as-needed} restores the default behaviour.
@kindex --add-needed
it. This option disallows symbols with undefined version and a fatal error
will be issued instead.
+@kindex --default-symver
+@item --default-symver
+Create and use a default symbol version (the soname) for unversioned
+exported symbols.
+
+@kindex --default-imported-symver
+@item --default-imported-symver
+Create and use a default symbol version (the soname) for unversioned
+imported symbols.
+
@kindex --no-warn-mismatch
@item --no-warn-mismatch
Normally @command{ld} will give an error if you try to link together input
Compute and display statistics about the operation of the linker, such
as execution time and memory usage.
+@kindex --sysroot
+@item --sysroot=@var{directory}
+Use @var{directory} as the location of the sysroot, overriding the
+configure-time default. This option is only supported by linkers
+that were configured using @option{--with-sysroot}.
+
@kindex --traditional-format
@cindex traditional format
@item --traditional-format
exported. The symbol names may be delimited by commas or colons.
[This option is specific to the i386 PE targeted port of the linker]
-@kindex --exclude-libs
-@item --exclude-libs @var{lib},@var{lib},...
-Specifies a list of archive libraries from which symbols should not be automatically
-exported. The library names may be delimited by commas or colons. Specifying
-@code{--exclude-libs ALL} excludes symbols in all archive libraries from
-automatic export. Symbols explicitly listed in a .def file are still exported,
-regardless of this option.
-[This option is specific to the i386 PE targeted port of the linker]
-
@kindex --file-alignment
@item --file-alignment
Specify the file alignment. Sections in the file will always begin at
@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.
+@code{console}, @code{posix}, and @code{xbox}. You may optionally set
+the subsystem version also. Numeric values are also accepted for
+@var{which}.
[This option is specific to the i386 PE targeted port of the linker]
@end table
new undefined references are created. See the description of @samp{-(}
in @ref{Options,,Command Line Options}.
+@item AS_NEEDED(@var{file}, @var{file}, @dots{})
+@itemx AS_NEEDED(@var{file} @var{file} @dots{})
+@kindex AS_NEEDED(@var{files})
+This construct can appear only inside of the @code{INPUT} or @code{GROUP}
+commands, among other filenames. The files listed will be handled
+as if they appear directly in the @code{INPUT} or @code{GROUP} commands,
+with the exception of ELF shared libraries, that will be added only
+when they are actually needed. This construct essentially enables
+@option{--as-needed} option for all the files listed inside of it
+and restores previous @option{--as-needed} resp. @option{--no-as-needed}
+setting afterwards.
+
@item OUTPUT(@var{filename})
@kindex OUTPUT(@var{filename})
@cindex output file name in linker scripot
@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.
+the symbol and place it into the symbol table with a global scope.
@menu
* Simple Assignments:: Simple Assignments
* PROVIDE:: PROVIDE
+* Source Code Reference:: How to use a linker script defined symbol in source code
@end menu
@node Simple Assignments
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.
+may only use this within a @code{SECTIONS} command. @xref{Location Counter}.
The semicolon after @var{expression} is required.
If the program references @samp{etext} but does not define it, the
linker will use the definition in the linker script.
+@node Source Code Reference
+@subsection Source Code Reference
+
+Accessing a linker script defined variable from source code is not
+intuitive. In particular a linker script symbol is not equivalent to
+a variable declaration in a high level language, it is instead a
+symbol that does not have a value.
+
+Before going further, it is important to note that compilers often
+transform names in the source code into different names when they are
+stored in the symbol table. For example, Fortran compilers commonly
+prepend or append an underscore, and C++ performs extensive @samp{name
+mangling}. Therefore there might be a discrepancy between the name
+of a variable as it is used in source code and the name of the same
+variable as it is defined in a linker script. For example in C a
+linker script variable might be referred to as:
+
+@smallexample
+ extern int foo;
+@end smallexample
+
+But in the linker script it might be defined as:
+
+@smallexample
+ _foo = 1000;
+@end smallexample
+
+In the remaining examples however it is assumed that no name
+transformation has taken place.
+
+When a symbol is declared in a high level language such as C, two
+things happen. The first is that the compiler reserves enough space
+in the program's memory to hold the @emph{value} of the symbol. The
+second is that the compiler creates an entry in the program's symbol
+table which holds the symbol's @emph{address}. ie the symbol table
+contains the address of the block of memory holding the symbol's
+value. So for example the following C declaration, at file scope:
+
+@smallexample
+ int foo = 1000;
+@end smallexample
+
+creates a entry called @samp{foo} in the symbol table. This entry
+holds the address of an @samp{int} sized block of memory where the
+number 1000 is initially stored.
+
+When a program references a symbol the compiler generates code that
+first accesses the symbol table to find the address of the symbol's
+memory block and then code to read the value from that memory block.
+So:
+
+@smallexample
+ foo = 1;
+@end smallexample
+
+looks up the symbol @samp{foo} in the symbol table, gets the address
+associated with this symbol and then writes the value 1 into that
+address. Whereas:
+
+@smallexample
+ int * a = & foo;
+@end smallexample
+
+looks up the symbol @samp{foo} in the symbol table, gets it address
+and then copies this address into the block of memory associated with
+the variable @samp{a}.
+
+Linker scripts symbol declarations, by contrast, create an entry in
+the symbol table but do not assign any memory to them. Thus they are
+an address without a value. So for example the linker script definition:
+
+@smallexample
+ foo = 1000;
+@end smallexample
+
+creates an entry in the symbol table called @samp{foo} which holds
+the address of memory location 1000, but nothing special is stored at
+address 1000. This means that you cannot access the @emph{value} of a
+linker script defined symbol - it has no value - all you can do is
+access the @emph{address} of a linker script defined symbol.
+
+Hence when you are using a linker script defined symbol in source code
+you should always take the address of the symbol, and never attempt to
+use its value. For example suppose you want to copy the contents of a
+section of memory called .ROM into a section called .FLASH and the
+linker script contains these declarations:
+
+@smallexample
+@group
+ start_of_ROM = .ROM;
+ end_of_ROM = .ROM + sizeof (.ROM) - 1;
+ start_of_FLASH = .FLASH;
+@end group
+@end smallexample
+
+Then the C source code to perform the copy would be:
+
+@smallexample
+@group
+ extern char start_of_ROM, end_of_ROM, start_of_FLASH;
+
+ memcpy (& start_of_FLASH, & start_of_ROM, & end_of_ROM - & start_of_ROM);
+@end group
+@end smallexample
+
+Note the use of the @samp{&} operators. These are correct.
+
@node SECTIONS
@section SECTIONS Command
@kindex SECTIONS
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
+constructors, and the symbol @w{@code{__CTOR_END__}} marks the end.
+Similarly, @w{@code{__DTOR_LIST__}} and @w{@code{__DTOR_END__}} mark
+the start and end of the global destructors. 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
@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}).
+The @var{origin} is an numerical expression for the start address of
+the memory region. The expression must evaluate to a constant and it
+cannot involve any 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}.
+be numerical only and must evaluate to a constant. 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,
output sections directed to a memory region are too large for the
region, the linker will issue an error message.
+It is possible to access the origin and length of a memory in an
+expression via the @code{ORIGIN(@var{memory})} and
+@code{LENGTH(@var{memory})} functions:
+
+@smallexample
+@group
+ _fstack = ORIGIN(ram) + LENGTH(ram) - 4;
+@end group
+@end smallexample
+
@node PHDRS
@section PHDRS Command
@kindex PHDRS
the values from the @samp{.data} input sections and before the end of
the @samp{.data} output section itself.
+@cindex dot outside sections
+Setting symbols to the value of the location counter outside of an
+output section statement can result in unexpected values if the linker
+needs to place orphan sections. For example, given the following:
+
+@smallexample
+SECTIONS
+@{
+ start_of_text = . ;
+ .text: @{ *(.text) @}
+ end_of_text = . ;
+
+ start_of_data = . ;
+ .data: @{ *(.data) @}
+ end_of_data = . ;
+@}
+@end smallexample
+
+If the linker needs to place some input section, e.g. @code{.rodata},
+not mentioned in the script, it might choose to place that section
+between @code{.text} and @code{.data}. You might think the linker
+should place @code{.rodata} on the blank line in the above script, but
+blank lines are of no particular significance to the linker. As well,
+the linker doesn't associate the above symbol names with their
+sections. Instead, it assumes that all assignments or other
+statements belong to the previous output section, except for the
+special case of an assignment to @code{.}. I.e., the linker will
+place the orphan @code{.rodata} section as if the script was written
+as follows:
+
+@smallexample
+SECTIONS
+@{
+ start_of_text = . ;
+ .text: @{ *(.text) @}
+ end_of_text = . ;
+
+ start_of_data = . ;
+ .rodata: @{ *(.rodata) @}
+ .data: @{ *(.data) @}
+ end_of_data = . ;
+@}
+@end smallexample
+
+This may or may not be the script author's intention for the value of
+@code{start_of_data}. One way to influence the orphan section
+placement is to assign the location counter to itself, as the linker
+assumes that an assignment to @code{.} is setting the start address of
+a following output section and thus should be grouped with that
+section. So you could write:
+
+@smallexample
+SECTIONS
+@{
+ start_of_text = . ;
+ .text: @{ *(.text) @}
+ end_of_text = . ;
+
+ . = . ;
+ start_of_data = . ;
+ .data: @{ *(.data) @}
+ end_of_data = . ;
+@}
+@end smallexample
+
+Now, the orphan @code{.rodata} section will be placed between
+@code{end_of_text} and @code{start_of_data}.
+
@need 2000
@node Operators
@subsection Operators
@end group
@end smallexample
+@item LENGTH(@var{memory})
+@kindex LENGTH(@var{memory})
+Return the length of the memory region named @var{memory}.
+
@item LOADADDR(@var{section})
@kindex LOADADDR(@var{section})
@cindex section load address in expression
use the @code{MEMORY} command to define discontinuous memory for the
output file, the two functions are equivalent.
+@item ORIGIN(@var{memory})
+@kindex ORIGIN(@var{memory})
+Return the origin of the memory region named @var{memory}.
+
+@item SEGMENT_START(@var{segment}, @var{default})
+@kindex SEGMENT_START(@var{segment}, @var{default})
+Return the base address of the named @var{segment}. If an explicit
+value has been given for this segment (with a command-line @samp{-T}
+option) that value will be returned; otherwise the value will be
+@var{default}. At present, the @samp{-T} command-line option can only
+be used to set the base address for the ``text'', ``data'', and
+``bss'' sections, but you use @code{SEGMENT_START} with any segment
+name.
+
@item SIZEOF(@var{section})
@kindex SIZEOF(@var{section})
@cindex section size
@samp{R_ARM_GOT_PREL} (arm*-*-linux, arm*-*-*bsd)
@end table
+@cindex FIX_V4BX
+@kindex --fix-v4bx
+The @samp{R_ARM_V4BX} relocation (defined by the ARM AAELF
+specification) enables objects compiled for the ARMv4 architecture to be
+interworking-safe when linked with other objects compiled for ARMv4t, but
+also allows pure ARMv4 binaries to be built from the same ARMv4 objects.
+
+In the latter case, the switch @option{--fix-v4bx} must be passed to the
+linker, which causes v4t @code{BX rM} instructions to be rewritten as
+@code{MOV PC,rM}, since v4 processors do not have a @code{BX} instruction.
+
+In the former case, the switch should not be used, and @samp{R_ARM_V4BX}
+relocations are ignored.
+
+@cindex USE_BLX
+@kindex --use-blx
+The @samp{--use-blx} switch enables the linker to use ARM/Thumb
+BLX instructions (available on ARMv5t and above) in various
+situations. Currently it is used to perform calls via the PLT from Thumb
+code using BLX rather than using BX and a mode-switching stub before
+each PLT entry. This should lead to such calls executing slightly faster.
+
+This option is enabled implicitly for SymbianOS, so there is no need to
+specify it if you are using that target.
+
@ifclear GENERIC
@lowersections
@end ifclear
projects / deliverable / binutils-gdb.git / blobdiff