* ld.texinfo (Options): Clarify --export-dynamic a bit.
This commit is contained in:
parent
fa8666c791
commit
5a59e34dd5
2 changed files with 252 additions and 28 deletions
|
@ -1,3 +1,7 @@
|
|||
Wed Jan 28 14:10:01 1998 Ian Lance Taylor <ian@cygnus.com>
|
||||
|
||||
* ld.texinfo (Options): Clarify --export-dynamic a bit.
|
||||
|
||||
Thu Jan 22 16:07:23 1998 Richard Henderson <rth@cygnus.com>
|
||||
|
||||
* ldlex.l (<SCRIPT>{WILDCHAR}*): Take care for the comments this
|
||||
|
|
276
ld/ld.texinfo
276
ld/ld.texinfo
|
@ -17,7 +17,7 @@ END-INFO-DIR-ENTRY
|
|||
@ifinfo
|
||||
This file documents the @sc{gnu} linker LD.
|
||||
|
||||
Copyright (C) 1991, 92, 93, 94, 95, 1996 Free Software Foundation, Inc.
|
||||
Copyright (C) 1991, 92, 93, 94, 95, 96, 1997 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of
|
||||
this manual provided the copyright notice and this permission notice
|
||||
|
@ -64,7 +64,7 @@ notice identical to this one except for the removal of this paragraph
|
|||
@end tex
|
||||
|
||||
@vskip 0pt plus 1filll
|
||||
Copyright @copyright{} 1991, 92, 93, 94, 95, 1996 Free Software Foundation, Inc.
|
||||
Copyright @copyright{} 1991, 92, 93, 94, 95, 96, 1997 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of
|
||||
this manual provided the copyright notice and this permission notice
|
||||
|
@ -328,9 +328,17 @@ entry point.
|
|||
@item -E
|
||||
@itemx --export-dynamic
|
||||
When creating a dynamically linked executable, add all symbols to the
|
||||
dynamic symbol table. Normally, the dynamic symbol table contains only
|
||||
symbols which are used by a dynamic object. This option is needed for
|
||||
some uses of @code{dlopen}.
|
||||
dynamic symbol table. The dynamic symbol table is the set of symbols
|
||||
which are visible from dynamic objects at run time.
|
||||
|
||||
If you do not use this option, the dynamic symbol table will normally
|
||||
contain only those symbols which are referenced by some dynamic object
|
||||
mentioned in the link.
|
||||
|
||||
If you use @code{dlopen} to load a dynamic object which needs to refer
|
||||
back to the symbols defined by the program, rather than some other
|
||||
dynamic object, then you will probably need to use this option when
|
||||
linking the program itself.
|
||||
|
||||
@kindex -f
|
||||
@kindex --auxiliary
|
||||
|
@ -351,6 +359,9 @@ Thus the shared object @var{name} may be used to provide an alternative
|
|||
implementation of certain functions, perhaps for debugging or for
|
||||
machine specific performance.
|
||||
|
||||
This option may be specified more than once. The DT_AUXILIARY entries
|
||||
will be created in the order in which they appear on the command line.
|
||||
|
||||
@kindex -F
|
||||
@kindex --filter
|
||||
@item -F @var{name}
|
||||
|
@ -783,6 +794,16 @@ instead optimize for memory usage, by rereading the symbol tables as
|
|||
necessary. This may be required if @code{ld} runs out of memory space
|
||||
while linking a large executable.
|
||||
|
||||
@kindex --no-warn-mismatch
|
||||
@item --no-warn-mismatch
|
||||
Normally @code{ld} will give an error if you try to link together input
|
||||
files that are mismatched for some reason, perhaps because they have
|
||||
been compiled for different processors or for different endiannesses.
|
||||
This option tells @code{ld} that it should silently permit such possible
|
||||
errors. This option should only be used with care, in cases when you
|
||||
have taken some special action that ensures that the linker errors are
|
||||
inappropriate.
|
||||
|
||||
@kindex --no-whole-archive
|
||||
@item --no-whole-archive
|
||||
Turn off the effect of the @code{--whole-archive} option for subsequent
|
||||
|
@ -1025,6 +1046,15 @@ 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 Script}.
|
||||
|
||||
@kindex --warn-comon
|
||||
@cindex warnings, on combining symbols
|
||||
@cindex combining symbols, warnings on
|
||||
|
@ -1253,6 +1283,7 @@ object or archive format, nor as a linker script, it reports an error.
|
|||
* SECTIONS:: SECTIONS Command
|
||||
* PHDRS:: PHDRS Command
|
||||
* Entry Point:: The Entry Point
|
||||
* Version Script:: Version Script
|
||||
* Option Commands:: Option Commands
|
||||
@end menu
|
||||
|
||||
|
@ -1825,11 +1856,38 @@ names. Use distinct names to specify multiple regions.
|
|||
|
||||
@cindex memory region attributes
|
||||
@item (@var{attr})
|
||||
is an optional list of attributes, permitted for compatibility with the
|
||||
AT&T linker but not used by @code{ld} beyond checking that the
|
||||
attribute list is valid. Valid attribute lists must be made up of the
|
||||
characters ``@code{LIRWX}''. If you omit the attribute list, you may
|
||||
omit the parentheses around it as well.
|
||||
is an optional list of attributes that specify whether to use a
|
||||
particular memory to place sections that are not listed in the linker
|
||||
script. Valid attribute lists must be made up of the characters
|
||||
``@code{ALIRWX}'' that match section attributes. If you omit the
|
||||
attribute list, you may omit the parentheses around it as well. The
|
||||
attributes currently supported are:
|
||||
|
||||
@table @samp
|
||||
@item @code{Letter}
|
||||
@code{Section Attribute}
|
||||
|
||||
@item @code{R}
|
||||
Read-only sections.
|
||||
|
||||
@item @code{W}
|
||||
Read/write sections.
|
||||
|
||||
@item @code{X}
|
||||
Sections containing executable code.
|
||||
|
||||
@item @code{A}
|
||||
Allocated sections.
|
||||
|
||||
@item @code{I}
|
||||
Initialized sections.
|
||||
|
||||
@item @code{L}
|
||||
Same as @code{I}.
|
||||
|
||||
@item @code{!}
|
||||
Invert the sense of any of the following attributes.
|
||||
@end table
|
||||
|
||||
@kindex ORIGIN =
|
||||
@kindex o =
|
||||
|
@ -1849,15 +1907,18 @@ The keyword @code{LENGTH} may be abbreviated to @code{len} or @code{l}.
|
|||
@end table
|
||||
|
||||
For example, to specify that memory has two regions available for
|
||||
allocation---one starting at 0 for 256 kilobytes, and the other
|
||||
starting at @code{0x40000000} for four megabytes:
|
||||
allocation---one starting at 0 for 256 kilobytes, and the other starting
|
||||
at @code{0x40000000} for four megabytes. The @code{rom} memory region
|
||||
will get all sections without an explicit memory register that are
|
||||
either read-only or contain code, while the @code{ram} memory region
|
||||
will get the sections.
|
||||
|
||||
@smallexample
|
||||
@group
|
||||
MEMORY
|
||||
@{
|
||||
rom : ORIGIN = 0, LENGTH = 256K
|
||||
ram : org = 0x40000000, l = 4M
|
||||
rom (rx) : ORIGIN = 0, LENGTH = 256K
|
||||
ram (!rx) : org = 0x40000000, l = 4M
|
||||
@}
|
||||
@end group
|
||||
@end smallexample
|
||||
|
@ -1932,9 +1993,10 @@ SECTIONS @{ @dots{}
|
|||
@noindent
|
||||
@var{secname} is the name of the output section, and @var{contents} a
|
||||
specification of what goes there---for example, a list of input files or
|
||||
sections of input files (@pxref{Section Placement}). As you might
|
||||
assume, the whitespace shown is optional. You do need the colon
|
||||
@samp{:} and the braces @samp{@{@}}, however.
|
||||
sections of input files (@pxref{Section Placement}). The whitespace
|
||||
around @var{secname} is required, so that the section name is
|
||||
unambiguous. The other whitespace shown is optional. You do need the
|
||||
colon @samp{:} and the braces @samp{@{@}}, however.
|
||||
|
||||
@var{secname} must meet the constraints of your output format. In
|
||||
formats which only support a limited number of sections, such as
|
||||
|
@ -2000,10 +2062,10 @@ statement.
|
|||
@item @var{filename}( @var{section} )
|
||||
@itemx @var{filename}( @var{section} , @var{section}, @dots{} )
|
||||
@itemx @var{filename}( @var{section} @var{section} @dots{} )
|
||||
You can name one or more sections from your input files, for
|
||||
insertion in the current output section. If you wish to specify a list
|
||||
of input-file sections inside the parentheses, you may separate the
|
||||
section names by either commas or whitespace.
|
||||
You can name one or more sections from your input files, for insertion
|
||||
in the current output section. If you wish to specify a list of
|
||||
input-file sections inside the parentheses, separate the section names
|
||||
with whitespace.
|
||||
|
||||
@cindex input sections to output section
|
||||
@kindex *(@var{section})
|
||||
|
@ -2254,15 +2316,20 @@ same value as @code{abs2}.
|
|||
@kindex SHORT(@var{expression})
|
||||
@kindex LONG(@var{expression})
|
||||
@kindex QUAD(@var{expression})
|
||||
@kindex SQUAD(@var{expression})
|
||||
@cindex direct output
|
||||
@item BYTE(@var{expression})
|
||||
@itemx SHORT(@var{expression})
|
||||
@itemx LONG(@var{expression})
|
||||
@itemx QUAD(@var{expression})
|
||||
@itemx SQUAD(@var{expression})
|
||||
By including one of these four statements in a section definition, you
|
||||
can explicitly place one, two, four, or eight bytes (respectively) at
|
||||
the current address of that section. @code{QUAD} is only supported when
|
||||
using a 64 bit host or target.
|
||||
can explicitly place one, two, four, eight unsigned, or eight signed
|
||||
bytes (respectively) at the current address of that section. When using
|
||||
a 64 bit host or target, @code{QUAD} and @code{SQUAD} are the same.
|
||||
When both host and target are 32 bits, @code{QUAD} uses an unsigned 32
|
||||
bit value, and @code{SQUAD} sign extends the value. Both will use the
|
||||
correct endianness when writing out the value.
|
||||
|
||||
@ifclear SingleFormat
|
||||
Multiple-byte quantities are represented in whatever byte order is
|
||||
|
@ -2343,10 +2410,13 @@ an expression.
|
|||
@cindex prevent unnecessary loading
|
||||
@cindex loading, preventing
|
||||
@item (NOLOAD)
|
||||
Use @samp{(NOLOAD)} to prevent a section from being loaded into memory
|
||||
each time it is accessed. For example, in the script sample below, the
|
||||
@code{ROM} segment is addressed at memory location @samp{0} and does not
|
||||
need to be loaded into each object file:
|
||||
The @samp{(NOLOAD)} directive will mark a section to not be loaded at
|
||||
run time. The linker will process the section normally, but will mark
|
||||
it so that a program loader will not load it into memory. For example,
|
||||
in the script sample below, the @code{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 @code{ROM} section will appear in the
|
||||
linker output file as usual.
|
||||
|
||||
@smallexample
|
||||
@group
|
||||
|
@ -2734,6 +2804,148 @@ whatever symbol contains the start address to @code{start}:
|
|||
start = other_symbol ;
|
||||
@end smallexample
|
||||
|
||||
@node Version Script
|
||||
@section Version Script
|
||||
@kindex VERSION @{script text@}
|
||||
@cindex symbol versions
|
||||
@cindex version script
|
||||
@cindex versions of symbols
|
||||
The linker command script includes a command specifically for
|
||||
specifying a version script, and is only meaningful for ELF platforms
|
||||
that support shared libraries. A version script can be
|
||||
build directly into the linker script that you are using, or you
|
||||
can supply the version script as just another input file to the linker
|
||||
at the time that you link. The command script syntax is:
|
||||
@smallexample
|
||||
VERSION @{ version script contents @}
|
||||
@end smallexample
|
||||
The version script can also be specified to the linker by means of the
|
||||
@samp{--version-script} linker command line option.
|
||||
Version scripts are only meaningful when creating shared libraries.
|
||||
|
||||
The format of the version script itself is identical to that used by
|
||||
Sun's linker in Solaris 2.5. Versioning is done by defining a tree of
|
||||
version nodes with the names and interdependencies specified in the
|
||||
version script. The version script can specify which symbols are bound
|
||||
to which version nodes, and it can reduce a specified set of symbols to
|
||||
local scope so that they are not globally visible outside of the shared
|
||||
library.
|
||||
|
||||
The easiest way to demonstrate the version script language is with a few
|
||||
examples.
|
||||
|
||||
@smallexample
|
||||
VERS_1.1 @{
|
||||
global:
|
||||
foo1;
|
||||
local:
|
||||
old*;
|
||||
original*;
|
||||
new*;
|
||||
@};
|
||||
|
||||
VERS_1.2 @{
|
||||
foo2;
|
||||
@} VERS_1.1;
|
||||
|
||||
VERS_2.0 @{
|
||||
bar1; bar2;
|
||||
@} VERS_1.2;
|
||||
@end smallexample
|
||||
|
||||
In this example, three version nodes are defined. @samp{VERS_1.1} is the
|
||||
first version node defined, and has no other dependencies. The symbol
|
||||
@samp{foo1} is bound to this version node, and a number of symbols
|
||||
that have appeared within various object files are reduced in scope to
|
||||
local so that they are not visible outside of the shared library.
|
||||
|
||||
Next, the node @samp{VERS_1.2} is defined. It depends upon
|
||||
@samp{VERS_1.1}. The symbol @samp{foo2} is bound to this version node.
|
||||
|
||||
Finally, the node @samp{VERS_2.0} is defined. It depends upon
|
||||
@samp{VERS_1.2}. The symbols @samp{bar1} and @samp{bar2} are bound to
|
||||
this version node.
|
||||
|
||||
Symbols defined in the library which aren't specifically bound to a
|
||||
version node are effectively bound to an unspecified base version of the
|
||||
library. It is possible to bind all otherwise unspecified symbols to a
|
||||
given version node using @samp{global: *} somewhere in the version
|
||||
script.
|
||||
|
||||
Lexically the names of the version nodes have no specific meaning other
|
||||
than what they might suggest to the person reading them. The @samp{2.0}
|
||||
version could just as well have appeared in between @samp{1.1} and
|
||||
@samp{1.2}. However, this would be a confusing way to write a version
|
||||
script.
|
||||
|
||||
When you link an application against a shared library that has versioned
|
||||
symbols, the application itself knows which version of each symbol it requires,
|
||||
and it also knows which version nodes it needs from each shared library it is
|
||||
linked against. Thus at runtime, the dynamic loader can make a quick check to
|
||||
make sure that the libraries you have linked against do in fact supply all
|
||||
of the version nodes that the application will need to resolve all of the
|
||||
dynamic symbols. In this way it is possible for the dynamic linker to know
|
||||
with certainty that all external symbols that it needs will be resolvable
|
||||
without having to search for each symbol reference.
|
||||
|
||||
The symbol versioning is in effect a much more sophisticated way of
|
||||
doing minor version checking that SunOS does. The fundamental problem
|
||||
that is being addressed here is that typically references to external
|
||||
functions are bound on an as-needed basis, and are not all bound when
|
||||
the application starts up. If a shared library is out of date, a
|
||||
required interface may be missing; when the application tries to use
|
||||
that interface, it may suddenly and unexpectedly fail. With symbol
|
||||
versioning, the user will get a warning when they start their program if
|
||||
the libraries being used with the application are too old.
|
||||
|
||||
There are several GNU extensions to Sun's versioning approach. The
|
||||
first of these is the ability to bind a symbol to a version node in the
|
||||
source file where the symbol is defined instead of in the versioning
|
||||
script. This was done mainly to reduce the burden on the library
|
||||
maintainer. This can be done by putting something like:
|
||||
|
||||
@smallexample
|
||||
__asm__(".symver original_foo,foo@@VERS_1.1");
|
||||
@end smallexample
|
||||
|
||||
in the C source file. This renamed the function @samp{original_foo} to
|
||||
be an alias for @samp{foo} bound to the version node @samp{VERS_1.1}.
|
||||
The @samp{local:} directive can be used to prevent the symbol
|
||||
@samp{original_foo} from being exported.
|
||||
|
||||
The second GNU extension is to allow multiple versions of the same function
|
||||
to appear in a given shared library. In this way an incompatible change to
|
||||
an interface can take place without increasing the major version number of
|
||||
the shared library, while still allowing applications linked against the old
|
||||
interface to continue to function.
|
||||
|
||||
This can only be accomplished by using multiple @samp{.symver}
|
||||
directives in the assembler. An example of this would be:
|
||||
|
||||
@smallexample
|
||||
__asm__(".symver original_foo,foo@@");
|
||||
__asm__(".symver old_foo,foo@@VERS_1.1");
|
||||
__asm__(".symver old_foo1,foo@@VERS_1.2");
|
||||
__asm__(".symver new_foo,foo@@@@VERS_2.0");
|
||||
@end smallexample
|
||||
|
||||
In this example, @samp{foo@@} represents the symbol @samp{foo} bound to the
|
||||
unspecified base version of the symbol. The source file that contains this
|
||||
example would define 4 C functions: @samp{original_foo}, @samp{old_foo},
|
||||
@samp{old_foo1}, and @samp{new_foo}.
|
||||
|
||||
When you have multiple definitions of a given symbol, there needs to be
|
||||
some way to specify a default version to which external references to
|
||||
this symbol will be bound. This can be accomplished with the
|
||||
@samp{foo@@@@VERS_2.0} type of @samp{.symver} directive. Only one version of
|
||||
a symbol can be declared 'default' in this manner - otherwise you would
|
||||
effectively have multiple definitions of the same symbol.
|
||||
|
||||
If you wish to bind a reference to a specific version of the symbol
|
||||
within the shared library, you can use the aliases of convenience
|
||||
(i.e. @samp{old_foo}), or you can use the @samp{.symver} directive to
|
||||
specifically bind to an external version of the function in question.
|
||||
|
||||
@node Option Commands
|
||||
@section Option Commands
|
||||
The command language includes a number of other commands that you can
|
||||
|
@ -2808,6 +3020,14 @@ 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}).
|
||||
|
||||
@kindex INCLUDE @var{filename}
|
||||
@cindex including a linker script
|
||||
@item INCLUDE @var{filename}
|
||||
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.
|
||||
|
||||
@kindex INPUT ( @var{files} )
|
||||
@cindex binary input files
|
||||
@item INPUT ( @var{file}, @var{file}, @dots{} )
|
||||
|
|
Loading…
Reference in a new issue