ldint.texinfo

基于4个mips核的noc设计

targets special symbols such as @code{_end} should be defined when doing
a final link.  Naturally, those symbols should not be defined when doing
a relocateable link using @code{-r}.  The @file{scripttempl} script
could use a construct like this to define those symbols:
@smallexample
  $@{RELOCATING+ _end = .;@}
@end smallexample
This will do the symbol assignment only if the @code{RELOCATING}
variable is defined.

The basic job of the linker script is to put the sections in the correct
order, and at the correct memory addresses.  For some targets, the
linker script may have to do some other operations.

For example, on most MIPS platforms, the linker is responsible for
defining the special symbol @code{_gp}, used to initialize the
@code{$gp} register.  It must be set to the start of the small data
section plus @code{0x8000}.  Naturally, it should only be defined when
doing a final relocation.  This will typically be done like this:
@smallexample
  $@{RELOCATING+ _gp = ALIGN(16) + 0x8000;@}
@end smallexample
This line would appear just before the sections which compose the small
data section (@samp{.sdata}, @samp{.sbss}).  All those sections would be
contiguous in memory.

Many COFF systems build constructor tables in the linker script.  The
compiler will arrange to output the address of each global constructor
in a @samp{.ctor} section, and the address of each global destructor in
a @samp{.dtor} section (this is done by defining
@code{ASM_OUTPUT_CONSTRUCTOR} and @code{ASM_OUTPUT_DESTRUCTOR} in the
@code{gcc} configuration files).  The @code{gcc} runtime support
routines expect the constructor table to be named @code{__CTOR_LIST__}.
They expect it to be a list of words, with the first word being the
count of the number of entries.  There should be a trailing zero word.
(Actually, the count may be -1 if the trailing word is present, and the
trailing word may be omitted if the count is correct, but, as the
@code{gcc} behaviour has changed slightly over the years, it is safest
to provide both).  Here is a typical way that might be handled in a
@file{scripttempl} file.
@smallexample
    $@{CONSTRUCTING+ __CTOR_LIST__ = .;@}
    $@{CONSTRUCTING+ LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)@}
    $@{CONSTRUCTING+ *(.ctors)@}
    $@{CONSTRUCTING+ LONG(0)@}
    $@{CONSTRUCTING+ __CTOR_END__ = .;@}
    $@{CONSTRUCTING+ __DTOR_LIST__ = .;@}
    $@{CONSTRUCTING+ LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)@}
    $@{CONSTRUCTING+ *(.dtors)@}
    $@{CONSTRUCTING+ LONG(0)@}
    $@{CONSTRUCTING+ __DTOR_END__ = .;@}
@end smallexample
The use of @code{CONSTRUCTING} ensures that these linker script commands
will only appear when the linker is supposed to be building the
constructor and destructor tables.  This example is written for a target
which uses 4 byte pointers.

Embedded systems often need to set a stack address.  This is normally
best done by using the @code{PROVIDE} construct with a default stack
address.  This permits the user to easily override the stack address
using the @code{--defsym} option.  Here is an example:
@smallexample
  $@{RELOCATING+ PROVIDE (__stack = 0x80000000);@}
@end smallexample
The value of the symbol @code{__stack} would then be used in the startup
code to initialize the stack pointer.

@node linker emulations
@section @file{emultempl} scripts

Each linker target uses an @file{emultempl} script to generate the
emulation code.  The name of the @file{emultempl} script is set by the
@code{TEMPLATE_NAME} variable in the @file{emulparams} script.  If the
@code{TEMPLATE_NAME} variable is not set, the default is
@samp{generic}.  If the value of @code{TEMPLATE_NAME} is @var{template},
@file{genscripts.sh} will use @file{emultempl/@var{template}.em}.

Most targets use the generic @file{emultempl} script,
@file{emultempl/generic.em}.  A different @file{emultempl} script is
only needed if the linker must support unusual actions, such as linking
against shared libraries.

The @file{emultempl} script is normally written as a simple invocation
of @code{cat} with a here document.  The document will use a few
variable substitutions.  Typically each function names uses a
substitution involving @code{EMULATION_NAME}, for ease of debugging when
the linker supports multiple emulations.

Every function and variable in the emitted file should be static.  The
only globally visible object must be named
@code{ld_@var{EMULATION_NAME}_emulation}, where @var{EMULATION_NAME} is
the name of the emulation set in @file{configure.tgt} (this is also the
name of the @file{emulparams} file without the @file{.sh} extension).
The @file{genscripts.sh} script will set the shell variable
@code{EMULATION_NAME} before invoking the @file{emultempl} script.

The @code{ld_@var{EMULATION_NAME}_emulation} variable must be a
@code{struct ld_emulation_xfer_struct}, as defined in @file{ldemul.h}.
It defines a set of function pointers which are invoked by the linker,
as well as strings for the emulation name (normally set from the shell
variable @code{EMULATION_NAME} and the default BFD target name (normally
set from the shell variable @code{OUTPUT_FORMAT} which is normally set
by the @file{emulparams} file).

The @file{genscripts.sh} script will set the shell variable
@code{COMPILE_IN} when it invokes the @file{emultempl} script for the
default emulation.  In this case, the @file{emultempl} script should
include the linker scripts directly, and return them from the
@code{get_scripts} entry point.  When the emulation is not the default,
the @code{get_scripts} entry point should just return a file name.  See
@file{emultempl/generic.em} for an example of how this is done.

At some point, the linker emulation entry points should be documented.

@node Emulation Walkthrough
@chapter A Walkthrough of a Typical Emulation

This chapter is to help people who are new to the way emulations
interact with the linker, or who are suddenly thrust into the position
of having to work with existing emulations.  It will discuss the files
you need to be aware of.  It will tell you when the given "hooks" in
the emulation will be called.  It will, hopefully, give you enough
information about when and how things happen that you'll be able to
get by.  As always, the source is the definitive reference to this.

The starting point for the linker is in @file{ldmain.c} where
@code{main} is defined.  The bulk of the code that's emulation
specific will initially be in @code{emultempl/@var{emulation}.em} but
will end up in @code{e@var{emulation}.c} when the build is done.
Most of the work to select and interface with emulations is in
@code{ldemul.h} and @code{ldemul.c}.  Specifically, @code{ldemul.h}
defines the @code{ld_emulation_xfer_struct} structure your emulation
exports.

Your emulation file exports a symbol
@code{ld_@var{EMULATION_NAME}_emulation}.  If your emulation is
selected (it usually is, since usually there's only one),
@code{ldemul.c} sets the variable @var{ld_emulation} to point to it.
@code{ldemul.c} also defines a number of API functions that interface
to your emulation, like @code{ldemul_after_parse} which simply calls
your @code{ld_@var{EMULATION}_emulation.after_parse} function.  For
the rest of this section, the functions will be mentioned, but you
should assume the indirect reference to your emulation also.

We will also skip or gloss over parts of the link process that don't
relate to emulations, like setting up internationalization.

After initialization, @code{main} selects an emulation by pre-scanning
the command line arguments.  It calls @code{ldemul_choose_target} to
choose a target.  If you set @code{choose_target} to
@code{ldemul_default_target}, it picks your @code{target_name} by
default.

@code{main} calls @code{ldemul_before_parse}, then @code{parse_args}.
@code{parse_args} calls @code{ldemul_parse_args} for each arg, which
must update the @code{getopt} globals if it recognizes the argument.
If the emulation doesn't recognize it, then parse_args checks to see
if it recognizes it.

Now that the emulation has had access to all its command-line options,
@code{main} calls @code{ldemul_set_symbols}.  This can be used for any
initialization that may be affected by options.  It is also supposed
to set up any variables needed by the emulation script.

@code{main} now calls @code{ldemul_get_script} to get the emulation
script to use (based on arguments, no doubt, @pxref{Emulations}) and
runs it.  While parsing, @code{ldgram.y} may call @code{ldemul_hll} or
@code{ldemul_syslib} to handle the @code{HLL} or @code{SYSLIB}
commands.  It may call @code{ldemul_unrecognized_file} if you asked
the linker to link a file it doesn't recognize.  It will call
@code{ldemul_recognized_file} for each file it does recognize, in case
the emulation wants to handle some files specially.  All the while,
it's loading the files (possibly calling
@code{ldemul_open_dynamic_archive}) and symbols and stuff.  After it's
done reading the script, @code{main} calls @code{ldemul_after_parse}.
Use the after-parse hook to set up anything that depends on stuff the
script might have set up, like the entry point.

@code{main} next calls @code{lang_process} in @code{ldlang.c}.  This
appears to be the main core of the linking itself, as far as emulation
hooks are concerned(*).  It first opens the output file's BFD, calling
@code{ldemul_set_output_arch}, and calls
@code{ldemul_create_output_section_statements} in case you need to use
other means to find or create object files (i.e. shared libraries
found on a path, or fake stub objects).  Despite the name, nobody
creates output sections here.

(*) In most cases, the BFD library does the bulk of the actual
linking, handling symbol tables, symbol resolution, relocations, and
building the final output file.  See the BFD reference for all the
details.  Your emulation is usually concerned more with managing
things at the file and section level, like "put this here, add this
section", etc.

Next, the objects to be linked are opened and BFDs created for them,
and @code{ldemul_after_open} is called.  At this point, you have all
the objects and symbols loaded, but none of the data has been placed
yet.

Next comes the Big Linking Thingy (except for the parts BFD does).
All input sections are mapped to output sections according to the
script.  If a section doesn't get mapped by default,
@code{ldemul_place_orphan} will get called to figure out where it goes.
Next it figures out the offsets for each section, calling
@code{ldemul_before_allocation} before and
@code{ldemul_after_allocation} after deciding where each input section
ends up in the output sections.

The last part of @code{lang_process} is to figure out all the symbols'
values.  After assigning final values to the symbols,
@code{ldemul_finish} is called, and after that, any undefined symbols
are turned into fatal errors.

OK, back to @code{main}, which calls @code{ldwrite} in
@file{ldwrite.c}.  @code{ldwrite} calls BFD's final_link, which does
all the relocation fixups and writes the output bfd to disk, and we're
done.

In summary,

@itemize @bullet

@item @code{main()} in @file{ldmain.c}
@item @file{emultempl/@var{EMULATION}.em} has your code
@item @code{ldemul_choose_target} (defaults to your @code{target_name})
@item @code{ldemul_before_parse}
@item Parse argv, calls @code{ldemul_parse_args} for each
@item @code{ldemul_set_symbols}
@item @code{ldemul_get_script}
@item parse script

@itemize @bullet
@item may call @code{ldemul_hll} or @code{ldemul_syslib}
@item may call @code{ldemul_open_dynamic_archive}
@end itemize

@item @code{ldemul_after_parse}
@item @code{lang_process()} in @file{ldlang.c}

@itemize @bullet
@item create @code{output_bfd}
@item @code{ldemul_set_output_arch}
@item @code{ldemul_create_output_section_statements}
@item read objects, create input bfds - all symbols exist, but have no values
@item may call @code{ldemul_unrecognized_file}
@item will call @code{ldemul_recognized_file}
@item @code{ldemul_after_open}
@item map input sections to output sections
@item may call @code{ldemul_place_orphan} for remaining sections
@item @code{ldemul_before_allocation}
@item gives input sections offsets into output sections, places output sections
@item @code{ldemul_after_allocation} - section addresses valid
@item assigns values to symbols
@item @code{ldemul_finish} - symbol values valid
@end itemize

@item output bfd is written to disk

@end itemize

@node GNU Free Documentation License
@chapter GNU Free Documentation License

                GNU Free Documentation License
                
                   Version 1.1, March 2000

 Copyright (C) 2000  Free Software Foundation, Inc.
  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
     
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.


0. PREAMBLE

The purpose of this License is to make a manual, textbook, or other
written document "free" in the sense of freedom: to assure everyone
the effective freedom to copy and redistribute it, with or without
modifying it, either commercially or noncommercially.  Secondarily,
this License preserves for the author and publisher a way to get
credit for their work, while not being considered responsible for
modifications made by others.

This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense.  It
complements the GNU General Public License, which is a copyleft
license designed for free software.

We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does.  But this License is not limited to software manuals;
it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book.  We recommend this License
principally for works whose purpose is instruction or reference.


1. APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work that contains a
notice placed by the copyright holder saying it can be distributed
under the terms of this License.  The "Document", below, refers to any
such manual or work.  Any member of the public is a licensee, and is
addressed as "you".

A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall subject