[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3. 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 `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,


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated by system on December, 2 2004 using texi2html