\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
+@c man begin INCLUDE
@include configdoc.texi
@c (configdoc.texi is generated by the Makefile)
@include ldver.texi
+@c man end
@c @smallbook
@c Configure for the generation of man pages
@set UsesEnvVars
@set GENERIC
-@set A29K
@set ARC
@set ARM
@set D10V
@set MSP430
@set PDP11
@set PJ
+@set POWERPC
+@set POWERPC64
@set SH
@set SPARC
@set TIC54X
@ifset M68HC11
* M68HC11/68HC12:: ld and the Motorola 68HC11 and 68HC12 families
@end ifset
+@ifset POWERPC
+* PowerPC ELF32:: ld and PowerPC 32-bit ELF Support
+@end ifset
+@ifset POWERPC64
+* PowerPC64 ELF64:: ld and PowerPC64 64-bit ELF Support
+@end ifset
@ifset TICOFF
* TI COFF:: ld and the TI COFF
@end ifset
linker:
@table @gcctabopt
+@include at-file.texi
+
@kindex -a@var{keyword}
@item -a@var{keyword}
This option is supported for HP/UX compatibility. The @var{keyword}
@itemize @bullet
@item
-Where object files and symbols are mapped into memory.
+Where object files are mapped into memory.
@item
How common symbols are allocated.
@item
All archive members included in the link, with a mention of the symbol
which caused the archive member to be brought in.
+@item
+The values assigned to symbols.
+
+Note - symbols whose values are computed by an expression which
+involves a reference to a previous value of the same symbol may not
+have correct result displayed in the link map. This is because the
+linker discards intermediate results and only retains the final value
+of an expression. Under such circumstances the linker will display
+the final value enclosed by square brackets. Thus for example a
+linker script containing:
+
+@smallexample
+ foo = 1
+ foo = foo * 4
+ foo = foo + 8
+@end smallexample
+
+will produce the following output in the link map if the @option{-M}
+option is used:
+
+@smallexample
+ 0x00000001 foo = 0x1
+ [0x0000000c] foo = (foo * 0x4)
+ [0x0000000c] foo = (foo + 0x8)
+@end smallexample
+
+See @ref{Expressions} for more information about expressions in linker
+scripts.
@end itemize
@kindex -n
This option is currently only supported on ELF platforms.
+@kindex --force-dynamic
+@cindex forcing the creation of dynamic sections
+@item --force-dynamic
+Force the output file to have dynamic sections. This option is specific
+to VxWorks targets.
+
@cindex partial link
@cindex relocatable output
@kindex -r
Disallows undefined symbols in object files. Undefined symbols in
shared libraries are still allowed.
+@item execstack
+Marks the object as requiring executable stack.
+
@item initfirst
This option is only meaningful when building a shared object.
It marks the object so that its runtime initialization will occur
@item nodump
Marks the object can not be dumped by @code{dldump}.
+@item noexecstack
+Marks the object as not requiring executable stack.
+
+@item norelro
+Don't create an ELF @code{PT_GNU_RELRO} segment header in the object.
+
@item now
When generating an executable or shared library, mark it to tell the
dynamic linker to resolve all symbols when the program is started, or
@item origin
Marks the object may contain $ORIGIN.
+@item relro
+Create an ELF @code{PT_GNU_RELRO} segment header in the object.
+
@end table
Other keywords are ignored for Solaris compatibility.
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
variants of this option are for compatibility with various systems. You
may use this option multiple times on the command line: it affects
library searching for @option{-l} options which follow it. This
-option also implies @option{--unresolved-symbols=report-all}.
+option also implies @option{--unresolved-symbols=report-all}. This
+option can be used with @option{-shared}. Doing so means that a
+shared library is being created but that all of the library's external
+references must be resolved by pulling in entries from static
+libraries.
@kindex -Bsymbolic
@item -Bsymbolic
@item --check-sections
@itemx --no-check-sections
Asks the linker @emph{not} to check section addresses after they have
-been assigned to see if there any overlaps. Normally the linker will
+been assigned to see if there are any overlaps. Normally the linker will
perform this check, and if it finds any overlaps it will produce
suitable error messages. The linker does know about, and does make
allowances for sections in overlays. The default behaviour can be
@ifset M68HC11
@xref{M68HC11/68HC12,,@command{ld} and the 68HC11 and 68HC12}.
@end ifset
+@ifset POWERPC
+@xref{PowerPC ELF32,,@command{ld} and PowerPC 32-bit ELF Support}.
+@end ifset
On some platforms, the @samp{--relax} option performs global
optimizations that become possible when the linker resolves addressing
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}.
+@kindex --eh-frame-hdr
+@item --eh-frame-hdr
+Request creation of @code{.eh_frame_hdr} section and ELF
+@code{PT_GNU_EH_FRAME} segment header.
+
@kindex --enable-new-dtags
@kindex --disable-new-dtags
@item --enable-new-dtags
those options are only available for ELF systems.
@kindex --hash-size=@var{number}
+@item --hash-size=@var{number}
Set the default size of the linker's hash tables to a prime number
close to @var{number}. Increasing this value can reduce the length of
time it takes the linker to perform its tasks, at the expense of
@kindex --reduce-memory-overheads
@item --reduce-memory-overheads
This option reduces memory requirements at ld runtime, at the expense of
-linking speed. This was introduced to to select the old O(n^2) algorithm
+linking speed. This was introduced to select the old O(n^2) algorithm
for link map file generation, rather than the new O(n) algorithm which uses
about 40% more memory for symbol storage.
-Another affect of the switch is to set the default hash table size to
+Another effect of the switch is to set the default hash table size to
1021, which again saves memory at the cost of lengthening the linker's
run time. This is not done however if the @option{--hash-size} switch
has been used.
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
+* PROVIDE_HIDDEN:: PROVIDE_HIDDEN
+* 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 PROVIDE_HIDDEN
+@subsection PROVIDE_HIDDEN
+@cindex PROVIDE_HIDDEN
+Similar to @code{PROVIDE}. For ELF targeted ports, the symbol will be
+hidden and won't be exported.
+
+@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
@smallexample
@group
@var{section} [@var{address}] [(@var{type})] :
- [AT(@var{lma})] [SUBALIGN(@var{subsection_align})]
+ [AT(@var{lma})] [ALIGN(@var{section_align})] [SUBALIGN(@var{subsection_align})]
@{
@var{output-section-command}
@var{output-section-command}
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
@smallexample
@group
@var{section} [@var{address}] [(@var{type})] :
- [AT(@var{lma})] [SUBALIGN(@var{subsection_align})]
+ [AT(@var{lma})] [ALIGN(@var{section_align})] [SUBALIGN(@var{subsection_align})]
@{
@var{output-section-command}
@var{output-section-command}
@menu
* Output Section Type:: Output section type
* Output Section LMA:: Output section LMA
+* Forced Output Alignment:: Forced Output Alignment
* Forced Input Alignment:: Forced Input Alignment
* Output Section Region:: Output section region
* Output Section Phdr:: Output section phdr
@end group
@end smallexample
+@node Forced Output Alignment
+@subsubsection Forced Output Alignment
+@kindex ALIGN(@var{section_align})
+@cindex forcing output section alignment
+@cindex output section alignment
+You can increase an output section's alignment by using ALIGN.
+
@node Forced Input Alignment
@subsubsection Forced Input Alignment
@kindex SUBALIGN(@var{subsection_align})
VERS_2.0 @{
bar1; bar2;
+ extern "C++" @{
+ ns::*;
+ "int f(int, double)";
+ @}
@} VERS_1.2;
@end smallexample
symbol whose name begins with @samp{old}, @samp{original}, or @samp{new}
is matched. The wildcard patterns available are the same as those used
in the shell when matching filenames (also known as ``globbing'').
+However, if you specify the symbol name inside double quotes, then the
+name is treated as literal, rather than as a glob pattern.
Next, the version script defines node @samp{VERS_1.2}. This node
depends upon @samp{VERS_1.1}. The script binds the symbol @samp{foo2}
demangle them according to @samp{lang} before matching them to the
patterns specified in @samp{version-script-commands}.
+Demangled names may contains spaces and other special characters. As
+described above, you can use a glob pattern to match demangled names,
+or you can use a double-quoted string to match the string exactly. In
+the latter case, be aware that minor differences (such as differing
+whitespace) between the version script and the demangler output will
+cause a mismatch. As the exact string generated by the demangler
+might change in the future, even if the mangled name does not, you
+should check that all of your version directives are behaving as you
+expect when you upgrade.
+
@node Expressions
@section Expressions in Linker Scripts
@cindex expressions
@menu
* Constants:: Constants
* Symbols:: Symbol Names
+* Orphan Sections:: Orphan Sections
* Location Counter:: The Location Counter
* Operators:: Operators
* Evaluation:: Evaluation
to delimit symbols with spaces. For example, @samp{A-B} is one symbol,
whereas @samp{A - B} is an expression involving subtraction.
+@node Orphan Sections
+@subsection Orphan Sections
+@cindex orphan
+Orphan sections are sections present in the input files which
+are not explicitly placed into the output file by the linker
+script. The linker will still copy these sections into the
+output file, but it has to guess as to where they should be
+placed. The linker uses a simple heuristic to do this. It
+attempts to place orphan sections after non-orphan sections of the
+same attribute, such as code vs data, loadable vs non-loadable, etc.
+If there is not enough room to do this then it places
+at the end of the file.
+
+For ELF targets, the attribute of the section includes section type as
+well as section flag.
+
@node Location Counter
@subsection The Location Counter
@kindex .
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
@ifset M68HC11
* M68HC11/68HC12:: @code{ld} and the Motorola 68HC11 and 68HC12 families
@end ifset
+@ifset POWERPC
+* PowerPC ELF32:: @command{ld} and PowerPC 32-bit ELF Support
+@end ifset
+@ifset POWERPC64
+* PowerPC64 ELF64:: @command{ld} and PowerPC64 64-bit ELF Support
+@end ifset
@ifset TICOFF
* TI COFF:: @command{ld} and TI COFF
@end ifset
@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
@end ifclear
@end ifset
+@ifset POWERPC
+@ifclear GENERIC
+@raisesections
+@end ifclear
+
+@node PowerPC ELF32
+@section @command{ld} and PowerPC 32-bit ELF Support
+@cindex PowerPC long branches
+@kindex --relax on PowerPC
+Branches on PowerPC processors are limited to a signed 26-bit
+displacement, which may result in @command{ld} giving
+@samp{relocation truncated to fit} errors with very large programs.
+@samp{--relax} enables the generation of trampolines that can access
+the entire 32-bit address space. These trampolines are inserted at
+section boundaries, so may not themselves be reachable if an input
+section exceeds 33M in size.
+
+@cindex PowerPC ELF32 options
+@table @option
+@cindex PowerPC PLT
+@kindex --bss-plt
+@item --bss-plt
+Current PowerPC GCC accepts a @samp{-msecure-plt} option that
+generates code capable of using a newer PLT and GOT layout that has
+the security advantage of no executable section ever needing to be
+writable and no writable section ever being executable. PowerPC
+@command{ld} will generate this layout, including stubs to access the
+PLT, if all input files (including startup and static libraries) were
+compiled with @samp{-msecure-plt}. @samp{--bss-plt} forces the old
+BSS PLT (and GOT layout) which can give slightly better performance.
+
+@cindex PowerPC GOT
+@kindex --sdata-got
+@item --sdata-got
+The new secure PLT and GOT are placed differently relative to other
+sections compared to older BSS PLT and GOT placement. The location of
+@code{.plt} must change because the new secure PLT is an initialized
+section while the old PLT is uninitialized. The reason for the
+@code{.got} change is more subtle: The new placement allows
+@code{.got} to be read-only in applications linked with
+@samp{-z relro -z now}. However, this placement means that
+@code{.sdata} cannot always be used in shared libraries, because the
+PowerPC ABI accesses @code{.sdata} in shared libraries from the GOT
+pointer. @samp{--sdata-got} forces the old GOT placement. PowerPC
+GCC doesn't use @code{.sdata} in shared libraries, so this option is
+really only useful for other compilers that may do so.
+
+@cindex PowerPC stub symbols
+@kindex --emit-stub-syms
+@item --emit-stub-syms
+This option causes @command{ld} to label linker stubs with a local
+symbol that encodes the stub type and destination.
+
+@cindex PowerPC TLS optimization
+@kindex --no-tls-optimize
+@item --no-tls-optimize
+PowerPC @command{ld} normally performs some optimization of code
+sequences used to access Thread-Local Storage. Use this option to
+disable the optimization.
+@end table
+
+@ifclear GENERIC
+@lowersections
+@end ifclear
+@end ifset
+
+@ifset POWERPC64
+@ifclear GENERIC
+@raisesections
+@end ifclear
+
+@node PowerPC64 ELF64
+@section @command{ld} and PowerPC64 64-bit ELF Support
+
+@cindex PowerPC64 ELF64 options
+@table @option
+@cindex PowerPC64 stub grouping
+@kindex --stub-group-size
+@item --stub-group-size
+Long branch stubs, PLT call stubs and TOC adjusting stubs are placed
+by @command{ld} in stub sections located between groups of input sections.
+@samp{--stub-group-size} specifies the maximum size of a group of input
+sections handled by one stub section. Since branch offsets are signed,
+a stub section may serve two groups of input sections, one group before
+the stub section, and one group after it. However, when using
+conditional branches that require stubs, it may be better (for branch
+prediction) that stub sections only serve one group of input sections.
+A negative value for @samp{N} chooses this scheme, ensuring that
+branches to stubs always use a negative offset. Two special values of
+@samp{N} are recognized, @samp{1} and @samp{-1}. These both instruct
+@command{ld} to automatically size input section groups for the branch types
+detected, with the same behaviour regarding stub placement as other
+positive or negative values of @samp{N} respectively.
+
+Note that @samp{--stub-group-size} does not split input sections. A
+single input section larger than the group size specified will of course
+create a larger group (of one section). If input sections are too
+large, it may not be possible for a branch to reach its stub.
+
+@cindex PowerPC64 stub symbols
+@kindex --emit-stub-syms
+@item --emit-stub-syms
+This option causes @command{ld} to label linker stubs with a local
+symbol that encodes the stub type and destination.
+
+@cindex PowerPC64 dot symbols
+@kindex --dotsyms
+@kindex --no-dotsyms
+@item --dotsyms, --no-dotsyms
+These two options control how @command{ld} interprets version patterns
+in a version script. Older PowerPC64 compilers emitted both a
+function descriptor symbol with the same name as the function, and a
+code entry symbol with the name prefixed by a dot (@samp{.}). To
+properly version a function @samp{foo}, the version script thus needs
+to control both @samp{foo} and @samp{.foo}. The option
+@samp{--dotsyms}, on by default, automatically adds the required
+dot-prefixed patterns. Use @samp{--no-dotsyms} to disable this
+feature.
+
+@cindex PowerPC64 TLS optimization
+@kindex --no-tls-optimize
+@item --no-tls-optimize
+PowerPC64 @command{ld} normally performs some optimization of code
+sequences used to access Thread-Local Storage. Use this option to
+disable the optimization.
+
+@cindex PowerPC64 OPD optimization
+@kindex --no-opd-optimize
+@item --no-opd-optimize
+PowerPC64 @command{ld} normally removes @code{.opd} section entries
+corresponding to deleted link-once functions, or functions removed by
+the action of @samp{--gc-sections} or linker scrip @code{/DISCARD/}.
+Use this option to disable @code{.opd} optimization.
+
+@cindex PowerPC64 OPD spacing
+@kindex --non-overlapping-opd
+@item --non-overlapping-opd
+Some PowerPC64 compilers have an option to generate compressed
+@code{.opd} entries spaced 16 bytes apart, overlapping the third word,
+the static chain pointer (unused in C) with the first word of the next
+entry. This option expands such entries to the full 24 bytes.
+
+@cindex PowerPC64 TOC optimization
+@kindex --no-toc-optimize
+@item --no-toc-optimize
+PowerPC64 @command{ld} normally removes unused @code{.toc} section
+entries. Such entries are detected by examining relocations that
+reference the TOC in code sections. A reloc in a deleted code section
+marks a TOC word as unneeded, while a reloc in a kept code section
+marks a TOC word as needed. Since the TOC may reference itself, TOC
+relocs are also examined. TOC words marked as both needed and
+unneeded will of course be kept. TOC words without any referencing
+reloc are assumed to be part of a multi-word entry, and are kept or
+discarded as per the nearest marked preceding word. This works
+reliably for compiler generated code, but may be incorrect if assembly
+code is used to insert TOC entries. Use this option to disable the
+optimization.
+
+@cindex PowerPC64 multi-TOC
+@kindex --no-multi-toc
+@item --no-multi-toc
+By default, PowerPC64 GCC generates code for a TOC model where TOC
+entries are accessed with a 16-bit offset from r2. This limits the
+total TOC size to 64K. PowerPC64 @command{ld} extends this limit by
+grouping code sections such that each group uses less than 64K for its
+TOC entries, then inserts r2 adjusting stubs between inter-group
+calls. @command{ld} does not split apart input sections, so cannot
+help if a single input file has a @code{.toc} section that exceeds
+64K, most likely from linking multiple files with @command{ld -r}.
+Use this option to turn off this feature.
+@end table
+
+@ifclear GENERIC
+@lowersections
+@end ifclear
+@end ifset
+
@ifset TICOFF
@ifclear GENERIC
@raisesections
Here is an example of a DEF file for a shared library called @samp{xyz.dll}:
@example
-LIBRARY "xyz.dll" BASE=0x10000000
+LIBRARY "xyz.dll" BASE=0x20000000
EXPORTS
foo
bar
_bar = bar
+another_foo = abc.dll.afoo
+var1 DATA
+@end example
+
+This example defines a DLL with a non-default base address and five
+symbols in the export table. The third exported symbol @code{_bar} is an
+alias for the second. The fourth symbol, @code{another_foo} is resolved
+by "forwarding" to another module and treating it as an alias for
+@code{afoo} exported from the DLL @samp{abc.dll}. The final symbol
+@code{var1} is declared to be a data object.
+
+The optional @code{LIBRARY <name>} command indicates the @emph{internal}
+name of the output DLL. If @samp{<name>} does not include a suffix,
+the default library suffix, @samp{.DLL} is appended.
+
+When the .DEF file is used to build an application. rather than a
+library, the @code{NAME <name>} command shoud be used instead of
+@code{LIBRARY}. If @samp{<name>} does not include a suffix, the default
+executable suffix, @samp{.EXE} is appended.
+
+With either @code{LIBRARY <name>} or @code{NAME <name>} the optional
+specification @code{BASE = <number>} may be used to specify a
+non-default base address for the image.
+
+If neither @code{LIBRARY <name>} nor @code{NAME <name>} is specified,
+or they specify an empty string, the internal name is the same as the
+filename specified on the command line.
+
+The complete specification of an export symbol is:
+
+@example
+EXPORTS
+ ( ( ( <name1> [ = <name2> ] )
+ | ( <name1> = <module-name> . <external-name>))
+ [ @@ <integer> ] [NONAME] [DATA] [CONSTANT] [PRIVATE] ) *
@end example
-This example defines a base address and three symbols. The third
-symbol is an alias for the second. For the complete format
-specification see ld/deffilep.y in the binutils sources.
+Declares @samp{<name1>} as an exported symbol from the DLL, or declares
+@samp{<name1>} as an exported alias for @samp{<name2>}; or declares
+@samp{<name1>} as a "forward" alias for the symbol
+@samp{<external-name>} in the DLL @samp{<module-name>}.
+Optionally, the symbol may be exported by the specified ordinal
+@samp{<integer>} alias.
+
+The optional keywords that follow the declaration indicate:
+
+@code{NONAME}: Do not put the symbol name in the DLL's export table. It
+will still be exported by its ordinal alias (either the value specified
+by the .def specification or, otherwise, the value assigned by the
+linker). The symbol name, however, does remain visible in the import
+library (if any), unless @code{PRIVATE} is also specified.
+
+@code{DATA}: The symbol is a variable or object, rather than a function.
+The import lib will export only an indirect reference to @code{foo} as
+the symbol @code{_imp__foo} (ie, @code{foo} must be resolved as
+@code{*_imp__foo}).
+
+@code{CONSTANT}: Like @code{DATA}, but put the undecorated @code{foo} as
+well as @code{_imp__foo} into the import library. Both refer to the
+read-only import address table's pointer to the variable, not to the
+variable itself. This can be dangerous. If the user code fails to add
+the @code{dllimport} attribute and also fails to explicitly add the
+extra indirection that the use of the attribute enforces, the
+application will behave unexpectedly.
+
+@code{PRIVATE}: Put the symbol in the DLL's export table, but do not put
+it into the static import library used to resolve imports at link time. The
+symbol can still be imported using the @code{LoadLibrary/GetProcAddress}
+API at runtime or by by using the GNU ld extension of linking directly to
+the DLL without an import library.
+
+See ld/deffilep.y in the binutils sources for the full specification of
+other DEF file statements
@cindex creating a DEF file
While linking a shared dll, @command{ld} is able to create a DEF file
projects / deliverable / binutils-gdb.git / blobdiff