[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 `ldmain.c' where
main
is defined. The bulk of the code that's emulation
specific will initially be in emultempl/emulation.em
but
will end up in eemulation.c
when the build is done.
Most of the work to select and interface with emulations is in
ldemul.h
and ldemul.c
. Specifically, ldemul.h
defines the ld_emulation_xfer_struct
structure your emulation
exports.
Your emulation file exports a symbol
ld_EMULATION_NAME_emulation
. If your emulation is
selected (it usually is, since usually there's only one),
ldemul.c
sets the variable ld_emulation to point to it.
ldemul.c
also defines a number of API functions that interface
to your emulation, like ldemul_after_parse
which simply calls
your ld_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, main
selects an emulation by pre-scanning
the command line arguments. It calls ldemul_choose_target
to
choose a target. If you set choose_target
to
ldemul_default_target
, it picks your target_name
by
default.
main
calls ldemul_before_parse
, then parse_args
.
parse_args
calls ldemul_parse_args
for each arg, which
must update the 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,
main
calls 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.
main
now calls ldemul_get_script
to get the emulation
script to use (based on arguments, no doubt, see section 2. How linker emulations are generated) and
runs it. While parsing, ldgram.y
may call ldemul_hll
or
ldemul_syslib
to handle the HLL
or SYSLIB
commands. It may call ldemul_unrecognized_file
if you asked
the linker to link a file it doesn't recognize. It will call
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
ldemul_open_dynamic_archive
) and symbols and stuff. After it's
done reading the script, main
calls 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.
main
next calls lang_process
in 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
ldemul_set_output_arch
, and calls
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 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,
ldemul_place_orphan
will get called to figure out where it goes.
Next it figures out the offsets for each section, calling
ldemul_before_allocation
before and
ldemul_after_allocation
after deciding where each input section
ends up in the output sections.
The last part of lang_process
is to figure out all the symbols'
values. After assigning final values to the symbols,
ldemul_finish
is called, and after that, any undefined symbols
are turned into fatal errors.
OK, back to main
, which calls ldwrite
in
`ldwrite.c'. 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,
main()
in `ldmain.c'
ldemul_choose_target
(defaults to your target_name
)
ldemul_before_parse
ldemul_parse_args
for each
ldemul_set_symbols
ldemul_get_script
ldemul_hll
or ldemul_syslib
ldemul_open_dynamic_archive
ldemul_after_parse
lang_process()
in `ldlang.c'
output_bfd
ldemul_set_output_arch
ldemul_create_output_section_statements
ldemul_unrecognized_file
ldemul_recognized_file
ldemul_after_open
ldemul_place_orphan
for remaining sections
ldemul_before_allocation
ldemul_after_allocation
- section addresses valid
ldemul_finish
- symbol values valid
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |