linker.texi

这个是LINUX下的GDB调度工具的源码

@section Linker Functions
@cindex Linker
The linker uses three special entry points in the BFD target
vector.  It is not necessary to write special routines for
these entry points when creating a new BFD back end, since
generic versions are provided.  However, writing them can
speed up linking and make it use significantly less runtime
memory.

The first routine creates a hash table used by the other
routines.  The second routine adds the symbols from an object
file to the hash table.  The third routine takes all the
object files and links them together to create the output
file.  These routines are designed so that the linker proper
does not need to know anything about the symbols in the object
files that it is linking.  The linker merely arranges the
sections as directed by the linker script and lets BFD handle
the details of symbols and relocs.

The second routine and third routines are passed a pointer to
a @code{struct bfd_link_info} structure (defined in
@code{bfdlink.h}) which holds information relevant to the link,
including the linker hash table (which was created by the
first routine) and a set of callback functions to the linker
proper.

The generic linker routines are in @code{linker.c}, and use the
header file @code{genlink.h}.  As of this writing, the only back
ends which have implemented versions of these routines are
a.out (in @code{aoutx.h}) and ECOFF (in @code{ecoff.c}).  The a.out
routines are used as examples throughout this section.

@menu
* Creating a Linker Hash Table::
* Adding Symbols to the Hash Table::
* Performing the Final Link::
@end menu

@node Creating a Linker Hash Table, Adding Symbols to the Hash Table, Linker Functions, Linker Functions
@subsection Creating a linker hash table
@cindex _bfd_link_hash_table_create in target vector
@cindex target vector (_bfd_link_hash_table_create)
The linker routines must create a hash table, which must be
derived from @code{struct bfd_link_hash_table} described in
@code{bfdlink.c}.  @xref{Hash Tables}, for information on how to
create a derived hash table.  This entry point is called using
the target vector of the linker output file.

The @code{_bfd_link_hash_table_create} entry point must allocate
and initialize an instance of the desired hash table.  If the
back end does not require any additional information to be
stored with the entries in the hash table, the entry point may
simply create a @code{struct bfd_link_hash_table}.  Most likely,
however, some additional information will be needed.

For example, with each entry in the hash table the a.out
linker keeps the index the symbol has in the final output file
(this index number is used so that when doing a relocatable
link the symbol index used in the output file can be quickly
filled in when copying over a reloc).  The a.out linker code
defines the required structures and functions for a hash table
derived from @code{struct bfd_link_hash_table}.  The a.out linker
hash table is created by the function
@code{NAME(aout,link_hash_table_create)}; it simply allocates
space for the hash table, initializes it, and returns a
pointer to it.

When writing the linker routines for a new back end, you will
generally not know exactly which fields will be required until
you have finished.  You should simply create a new hash table
which defines no additional fields, and then simply add fields
as they become necessary.

@node Adding Symbols to the Hash Table, Performing the Final Link, Creating a Linker Hash Table, Linker Functions
@subsection Adding symbols to the hash table
@cindex _bfd_link_add_symbols in target vector
@cindex target vector (_bfd_link_add_symbols)
The linker proper will call the @code{_bfd_link_add_symbols}
entry point for each object file or archive which is to be
linked (typically these are the files named on the command
line, but some may also come from the linker script).  The
entry point is responsible for examining the file.  For an
object file, BFD must add any relevant symbol information to
the hash table.  For an archive, BFD must determine which
elements of the archive should be used and adding them to the
link.

The a.out version of this entry point is
@code{NAME(aout,link_add_symbols)}.

@menu
* Differing file formats::
* Adding symbols from an object file::
* Adding symbols from an archive::
@end menu

@node Differing file formats, Adding symbols from an object file, Adding Symbols to the Hash Table, Adding Symbols to the Hash Table
@subsubsection Differing file formats
Normally all the files involved in a link will be of the same
format, but it is also possible to link together different
format object files, and the back end must support that.  The
@code{_bfd_link_add_symbols} entry point is called via the target
vector of the file to be added.  This has an important
consequence: the function may not assume that the hash table
is the type created by the corresponding
@code{_bfd_link_hash_table_create} vector.  All the
@code{_bfd_link_add_symbols} function can assume about the hash
table is that it is derived from @code{struct
bfd_link_hash_table}.

Sometimes the @code{_bfd_link_add_symbols} function must store
some information in the hash table entry to be used by the
@code{_bfd_final_link} function.  In such a case the @code{creator}
field of the hash table must be checked to make sure that the
hash table was created by an object file of the same format.

The @code{_bfd_final_link} routine must be prepared to handle a
hash entry without any extra information added by the
@code{_bfd_link_add_symbols} function.  A hash entry without
extra information will also occur when the linker script
directs the linker to create a symbol.  Note that, regardless
of how a hash table entry is added, all the fields will be
initialized to some sort of null value by the hash table entry
initialization function.

See @code{ecoff_link_add_externals} for an example of how to
check the @code{creator} field before saving information (in this
case, the ECOFF external symbol debugging information) in a
hash table entry.

@node Adding symbols from an object file, Adding symbols from an archive, Differing file formats, Adding Symbols to the Hash Table
@subsubsection Adding symbols from an object file
When the @code{_bfd_link_add_symbols} routine is passed an object
file, it must add all externally visible symbols in that
object file to the hash table.  The actual work of adding the
symbol to the hash table is normally handled by the function
@code{_bfd_generic_link_add_one_symbol}.  The
@code{_bfd_link_add_symbols} routine is responsible for reading
all the symbols from the object file and passing the correct
information to @code{_bfd_generic_link_add_one_symbol}.

The @code{_bfd_link_add_symbols} routine should not use
@code{bfd_canonicalize_symtab} to read the symbols.  The point of
providing this routine is to avoid the overhead of converting
the symbols into generic @code{asymbol} structures.

@findex _bfd_generic_link_add_one_symbol
@code{_bfd_generic_link_add_one_symbol} handles the details of
combining common symbols, warning about multiple definitions,
and so forth.  It takes arguments which describe the symbol to
add, notably symbol flags, a section, and an offset.  The
symbol flags include such things as @code{BSF_WEAK} or
@code{BSF_INDIRECT}.  The section is a section in the object
file, or something like @code{bfd_und_section_ptr} for an undefined
symbol or @code{bfd_com_section_ptr} for a common symbol.

If the @code{_bfd_final_link} routine is also going to need to
read the symbol information, the @code{_bfd_link_add_symbols}
routine should save it somewhere attached to the object file
BFD.  However, the information should only be saved if the
@code{keep_memory} field of the @code{info} argument is TRUE, so
that the @code{-no-keep-memory} linker switch is effective.

The a.out function which adds symbols from an object file is
@code{aout_link_add_object_symbols}, and most of the interesting
work is in @code{aout_link_add_symbols}.  The latter saves
pointers to the hash tables entries created by
@code{_bfd_generic_link_add_one_symbol} indexed by symbol number,
so that the @code{_bfd_final_link} routine does not have to call
the hash table lookup routine to locate the entry.

@node Adding symbols from an archive, , Adding symbols from an object file, Adding Symbols to the Hash Table
@subsubsection Adding symbols from an archive
When the @code{_bfd_link_add_symbols} routine is passed an
archive, it must look through the symbols defined by the
archive and decide which elements of the archive should be
included in the link.  For each such element it must call the
@code{add_archive_element} linker callback, and it must add the
symbols from the object file to the linker hash table.

@findex _bfd_generic_link_add_archive_symbols
In most cases the work of looking through the symbols in the
archive should be done by the
@code{_bfd_generic_link_add_archive_symbols} function.  This
function builds a hash table from the archive symbol table and
looks through the list of undefined symbols to see which
elements should be included.
@code{_bfd_generic_link_add_archive_symbols} is passed a function
to call to make the final decision about adding an archive
element to the link and to do the actual work of adding the
symbols to the linker hash table.