This is bfd.info, produced by makeinfo version 4.1 from bfd.texinfo. START-INFO-DIR-ENTRY * Bfd: (bfd). The Binary File Descriptor library. END-INFO-DIR-ENTRY This file documents the BFD library. Copyright (C) 1991, 2000, 2001 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".  File: bfd.info, Node: File Caching, Next: Linker Functions, Prev: Internal, Up: BFD front end File caching ============ The file caching mechanism is embedded within BFD and allows the application to open as many BFDs as it wants without regard to the underlying operating system's file descriptor limit (often as low as 20 open files). The module in `cache.c' maintains a least recently used list of `BFD_CACHE_MAX_OPEN' files, and exports the name `bfd_cache_lookup', which runs around and makes sure that the required BFD is open. If not, then it chooses a file to close, closes it and opens the one wanted, returning its file handle. `BFD_CACHE_MAX_OPEN macro' .......................... *Description* The maximum number of files which the cache will keep open at one time. #define BFD_CACHE_MAX_OPEN 10 `bfd_last_cache' ................ *Synopsis* extern bfd *bfd_last_cache; *Description* Zero, or a pointer to the topmost BFD on the chain. This is used by the `bfd_cache_lookup' macro in `libbfd.h' to determine when it can avoid a function call. `bfd_cache_lookup' .................. *Description* Check to see if the required BFD is the same as the last one looked up. If so, then it can use the stream in the BFD with impunity, since it can't have changed since the last lookup; otherwise, it has to perform the complicated lookup function. #define bfd_cache_lookup(x) \ ((x)==bfd_last_cache? \ (FILE*) (bfd_last_cache->iostream): \ bfd_cache_lookup_worker(x)) `bfd_cache_init' ................ *Synopsis* boolean bfd_cache_init (bfd *abfd); *Description* Add a newly opened BFD to the cache. `bfd_cache_close' ................. *Synopsis* boolean bfd_cache_close (bfd *abfd); *Description* Remove the BFD ABFD from the cache. If the attached file is open, then close it too. *Returns* `false' is returned if closing the file fails, `true' is returned if all is well. `bfd_open_file' ............... *Synopsis* FILE* bfd_open_file(bfd *abfd); *Description* Call the OS to open a file for ABFD. Return the `FILE *' (possibly `NULL') that results from this operation. Set up the BFD so that future accesses know the file is open. If the `FILE *' returned is `NULL', then it won't have been put in the cache, so it won't have to be removed from it. `bfd_cache_lookup_worker' ......................... *Synopsis* FILE *bfd_cache_lookup_worker(bfd *abfd); *Description* Called when the macro `bfd_cache_lookup' fails to find a quick answer. Find a file descriptor for ABFD. If necessary, it open it. If there are already more than `BFD_CACHE_MAX_OPEN' files open, it tries to close one first, to avoid running out of file descriptors.  File: bfd.info, Node: Linker Functions, Next: Hash Tables, Prev: File Caching, Up: BFD front end Linker Functions ================ 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 `struct bfd_link_info' structure (defined in `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 `linker.c', and use the header file `genlink.h'. As of this writing, the only back ends which have implemented versions of these routines are a.out (in `aoutx.h') and ECOFF (in `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::  File: bfd.info, Node: Creating a Linker Hash Table, Next: Adding Symbols to the Hash Table, Prev: Linker Functions, Up: Linker Functions Creating a linker hash table ---------------------------- The linker routines must create a hash table, which must be derived from `struct bfd_link_hash_table' described in `bfdlink.c'. *Note 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 `_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 `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 relocateable 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 `struct bfd_link_hash_table'. The a.out linker hash table is created by the function `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.  File: bfd.info, Node: Adding Symbols to the Hash Table, Next: Performing the Final Link, Prev: Creating a Linker Hash Table, Up: Linker Functions Adding symbols to the hash table -------------------------------- The linker proper will call the `_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 `NAME(aout,link_add_symbols)'. * Menu: * Differing file formats:: * Adding symbols from an object file:: * Adding symbols from an archive::  File: bfd.info, Node: Differing file formats, Next: Adding symbols from an object file, Prev: Adding Symbols to the Hash Table, Up: Adding Symbols to the Hash Table 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 `_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 `_bfd_link_hash_table_create' vector. All the `_bfd_link_add_symbols' function can assume about the hash table is that it is derived from `struct bfd_link_hash_table'. Sometimes the `_bfd_link_add_symbols' function must store some information in the hash table entry to be used by the `_bfd_final_link' function. In such a case the `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 `_bfd_final_link' routine must be prepared to handle a hash entry without any extra information added by the `_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 `ecoff_link_add_externals' for an example of how to check the `creator' field before saving information (in this case, the ECOFF external symbol debugging information) in a hash table entry.  File: bfd.info, Node: Adding symbols from an object file, Next: Adding symbols from an archive, Prev: Differing file formats, Up: Adding Symbols to the Hash Table Adding symbols from an object file .................................. When the `_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 `_bfd_generic_link_add_one_symbol'. The `_bfd_link_add_symbols' routine is responsible for reading all the symbols from the object file and passing the correct information to `_bfd_generic_link_add_one_symbol'. The `_bfd_link_add_symbols' routine should not use `bfd_canonicalize_symtab' to read the symbols. The point of providing this routine is to avoid the overhead of converting the symbols into generic `asymbol' structures. `_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 `BSF_WEAK' or `BSF_INDIRECT'. The section is a section in the object file, or something like `bfd_und_section_ptr' for an undefined symbol or `bfd_com_section_ptr' for a common symbol. If the `_bfd_final_link' routine is also going to need to read the symbol information, the `_bfd_link_add_symbols' routine should save it somewhere attached to the object file BFD. However, the information should only be saved if the `keep_memory' field of the `info' argument is true, so that the `-no-keep-memory' linker switch is effective. The a.out function which adds symbols from an object file is `aout_link_add_object_symbols', and most of the interesting work is in `aout_link_add_symbols'. The latter saves pointers to the hash tables entries created by `_bfd_generic_link_add_one_symbol' indexed by symbol number, so that the `_bfd_final_link' routine does not have to call the hash table lookup routine to locate the entry.  File: bfd.info, Node: Adding symbols from an archive, Prev: Adding symbols from an object file, Up: Adding Symbols to the Hash Table Adding symbols from an archive .............................. When the `_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 `add_archive_element' linker callback, and it must add the symbols from the object file to the linker hash table. In most cases the work of looking through the symbols in the archive should be done by the `_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. `_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. The function passed to `_bfd_generic_link_add_archive_symbols' must read the symbols of the archive element and decide whether the archive element should be included in the link. If the element is to be included, the `add_archive_element' linker callback routine must be called with the element as an argument, and the elements symbols must be added to the linker hash table just as though the element had itself been passed to the `_bfd_link_add_symbols' function. When the a.out `_bfd_link_add_symbols' function receives an archive, it calls `_bfd_generic_link_add_archive_symbols' passing `aout_link_check_archive_element' as the function argument. `aout_link_check_archive_element' calls `aout_link_check_ar_symbols'. If the latter decides to add the element (an element is only added if it provides a real, non-common, definition for a previously undefined or common symbol) it calls the `add_archive_element' callback and then `aout_link_check_archive_element' calls `aout_link_add_symbols' to actually add the symbols to the linker hash table. The ECOFF back end is unusual in that it does not normally call `_bfd_generic_link_add_archive_symbols', because ECOFF archives already contain a hash table of symbols. The ECOFF back end searches the archive itself to avoid the overhead of creating a new hash table.  File: bfd.info, Node: Performing the Final Link, Prev: Adding Symbols to the Hash Table, Up: Linker Functions Performing the final link ------------------------- When all the input files have been processed, the linker calls the `_bfd_final_link' entry point of the output BFD. This routine is responsible for producing the final output file, which has several aspects. It must relocate the contents of the input sections and copy the data into the output sections. It must build an output symbol table including any local symbols from the input files and the global symbols from the hash table. When producing relocateable output, it must modify the input relocs and write them into the output file. There may also be object format dependent work to be done. The linker will also call the `write_object_contents' entry point when the BFD is closed. The two entry points must work together in order to produce the correct output file. The details of how this works are inevitably dependent upon the specific object file format. The a.out `_bfd_final_link' routine is `NAME(aout,final_link)'. * Menu: * Information provided by the linker:: * Relocating the section contents:: * Writing the symbol table::  File: bfd.info, Node: Information provided by the linker, Next: Relocating the section contents, Prev: Performing the Final Link, Up: Performing the Final Link Information provided by the linker .................................. Before the linker calls the `_bfd_final_link' entry point, it sets up some data structures for the function to use. The `input_bfds' field of the `bfd_link_info' structure will point to a list of all the input files included in the link. These files are linked through the `link_next' field of the `bfd' structure. Each section in the output file will have a list of `link_order' structures attached to the `link_order_head' field (the `link_order' structure is defined in `bfdlink.h'). These structures describe how to create the contents of the output section in terms of the contents of various input sections, fill constants, and, eventually, other types of information. They also describe relocs that must be created by the BFD backend, but do not correspond to any input file; this is used to support -Ur, which builds constructors while generating a relocateable object file.  File: bfd.info, Node: Relocating the section contents, Next: Writing the symbol table, Prev: Information provided by the linker, Up: Performing the Final Link Relocating the section contents ............................... The `_bfd_final_link' function should look through the `link_order' structures attached to each section of the output file. Each `link_order' structure should either be handled specially, or it should be passed to the function `_bfd_default_link_order' which will do the right thing (`_bfd_default_link_order' is defined in `linker.c'). For efficiency, a `link_order' of type `bfd_indirect_link_order' whose associated section belongs to a BFD of the same format as the output BFD must be handled specially. This type of `link_order' describes part of an output section in terms of a section belonging to one of the input files. The `_bfd_final_link' function should read the contents of the section and any associated relocs, apply the relocs to the section contents, and write out the modified section contents. If performing a relocateable link, the relocs themselves must also be modified and written out. The functions `_bfd_relocate_contents' and `_bfd_final_link_relocate' provide some general support for performing the actual relocations, notably overflow checking. Their arguments include information about the symbol the relocation is against and a `reloc_howto_type' argument which describes the relocation to perform. These functions are defined in `reloc.c'. The a.out function which handles reading, relocating, and writing section contents is `aout_link_input_section'. The actual relocation is done in `aout_link_input_section_std' and `aout_link_input_section_ext'.  File: bfd.info, Node: Writing the symbol table, Prev: Relocating the section contents, Up: Performing the Final Link Writing the symbol table ........................ The `_bfd_final_link' function must gather all the symbols in the input files and write them out. It must also write out all the symbols in the global hash table. This must be controlled by the `strip' and `discard' fields of the `bfd_link_info' structure. The local symbols of the input files will not have been entered into the linker hash table. The `_bfd_final_link' routine must consider each input file and include the symbols in the output file. It may be convenient to do this when looking through the `link_order' structures, or it may be done by stepping through the `input_bfds' list. The `_bfd_final_link' routine must also traverse the global hash table to gather all the externally visible symbols. It is possible that most of the externally visible symbols may be written out when considering the symbols of each input file, but it is still necessary to traverse the hash table since the linker script may have defined some symbols that are not in any of the input files. The `strip' field of the `bfd_link_info' structure controls which symbols are written out. The possible values are listed in `bfdlink.h'. If the value is `strip_some', then the `keep_hash' field of the `bfd_link_info' structure is a hash table of symbols to keep; each symbol should be looked up in this hash table, and only symbols which are present should be included in the output file. If the `strip' field of the `bfd_link_info' structure permits local symbols to be written out, the `discard' field is used to further controls which local symbols are included in the output file. If the value is `discard_l', then all local symbols which begin with a certain prefix are discarded; this is controlled by the `bfd_is_local_label_name' entry point. The a.out backend handles symbols by calling `aout_link_write_symbols' on each input BFD and then traversing the global hash table with the function `aout_link_write_other_symbol'. It builds a string table while writing out the symbols, which is written to the output file at the end of `NAME(aout,final_link)'. `bfd_link_split_section' ........................ *Synopsis* boolean bfd_link_split_section(bfd *abfd, asection *sec); *Description* Return nonzero if SEC should be split during a reloceatable or final link. #define bfd_link_split_section(abfd, sec) \ BFD_SEND (abfd, _bfd_link_split_section, (abfd, sec))  File: bfd.info, Node: Hash Tables, Prev: Linker Functions, Up: BFD front end Hash Tables =========== BFD provides a simple set of hash table functions. Routines are provided to initialize a hash table, to free a hash table, to look up a string in a hash table and optionally create an entry for it, and to traverse a hash table. There is currently no routine to delete an string from a hash table. The basic hash table does not permit any data to be stored with a string. However, a hash table is designed to present a base class from which other types of hash tables may be derived. These derived types may store additional information with the string. Hash tables were implemented in this way, rather than simply providing a data pointer in a hash table entry, because they were designed for use by the linker back ends. The linker may create thousands of hash table entries, and the overhead of allocating private data and storing and following pointers becomes noticeable. The basic hash table code is in `hash.c'. * Menu: * Creating and Freeing a Hash Table:: * Looking Up or Entering a String:: * Traversing a Hash Table:: * Deriving a New Hash Table Type::  File: bfd.info, Node: Creating and Freeing a Hash Table, Next: Looking Up or Entering a String, Prev: Hash Tables, Up: Hash Tables Creating and freeing a hash table --------------------------------- To create a hash table, create an instance of a `struct bfd_hash_table' (defined in `bfd.h') and call `bfd_hash_table_init' (if you know approximately how many entries you will need, the function `bfd_hash_table_init_n', which takes a SIZE argument, may be used). `bfd_hash_table_init' returns `false' if some sort of error occurs. The function `bfd_hash_table_init' take as an argument a function to use to create new entries. For a basic hash table, use the function `bfd_hash_newfunc'. *Note Deriving a New Hash Table Type::, for why you would want to use a different value for this argument. `bfd_hash_table_init' will create an objalloc which will be used to allocate new entries. You may allocate memory on this objalloc using `bfd_hash_allocate'. Use `bfd_hash_table_free' to free up all the memory that has been allocated for a hash table. This will not free up the `struct bfd_hash_table' itself, which you must provide.  File: bfd.info, Node: Looking Up or Entering a String, Next: Traversing a Hash Table, Prev: Creating and Freeing a Hash Table, Up: Hash Tables Looking up or entering a string ------------------------------- The function `bfd_hash_lookup' is used both to look up a string in the hash table and to create a new entry. If the CREATE argument is `false', `bfd_hash_lookup' will look up a string. If the string is found, it will returns a pointer to a `struct bfd_hash_entry'. If the string is not found in the table `bfd_hash_lookup' will return `NULL'. You should not modify any of the fields in the returns `struct bfd_hash_entry'. If the CREATE argument is `true', the string will be entered into the hash table if it is not already there. Either way a pointer to a `struct bfd_hash_entry' will be returned, either to the existing structure or to a newly created one. In this case, a `NULL' return means that an error occurred. If the CREATE argument is `true', and a new entry is created, the COPY argument is used to decide whether to copy the string onto the hash table objalloc or not. If COPY is passed as `false', you must be careful not to deallocate or modify the string as long as the hash table exists.  File: bfd.info, Node: Traversing a Hash Table, Next: Deriving a New Hash Table Type, Prev: Looking Up or Entering a String, Up: Hash Tables Traversing a hash table ----------------------- The function `bfd_hash_traverse' may be used to traverse a hash table, calling a function on each element. The traversal is done in a random order. `bfd_hash_traverse' takes as arguments a function and a generic `void *' pointer. The function is called with a hash table entry (a `struct bfd_hash_entry *') and the generic pointer passed to `bfd_hash_traverse'. The function must return a `boolean' value, which indicates whether to continue traversing the hash table. If the function returns `false', `bfd_hash_traverse' will stop the traversal and return immediately.  File: bfd.info, Node: Deriving a New Hash Table Type, Prev: Traversing a Hash Table, Up: Hash Tables Deriving a new hash table type ------------------------------ Many uses of hash tables want to store additional information which each entry in the hash table. Some also find it convenient to store additional information with the hash table itself. This may be done using a derived hash table. Since C is not an object oriented language, creating a derived hash table requires sticking together some boilerplate routines with a few differences specific to the type of hash table you want to create. An example of a derived hash table is the linker hash table. The structures for this are defined in `bfdlink.h'. The functions are in `linker.c'. You may also derive a hash table from an already derived hash table. For example, the a.out linker backend code uses a hash table derived from the linker hash table. * Menu: * Define the Derived Structures:: * Write the Derived Creation Routine:: * Write Other Derived Routines::  File: bfd.info, Node: Define the Derived Structures, Next: Write the Derived Creation Routine, Prev: Deriving a New Hash Table Type, Up: Deriving a New Hash Table Type Define the derived structures ............................. You must define a structure for an entry in the hash table, and a structure for the hash table itself. The first field in the structure for an entry in the hash table must be of the type used for an entry in the hash table you are deriving from. If you are deriving from a basic hash table this is `struct bfd_hash_entry', which is defined in `bfd.h'. The first field in the structure for the hash table itself must be of the type of the hash table you are deriving from itself. If you are deriving from a basic hash table, this is `struct bfd_hash_table'. For example, the linker hash table defines `struct bfd_link_hash_entry' (in `bfdlink.h'). The first field, `root', is of type `struct bfd_hash_entry'. Similarly, the first field in `struct bfd_link_hash_table', `table', is of type `struct bfd_hash_table'.  File: bfd.info, Node: Write the Derived Creation Routine, Next: Write Other Derived Routines, Prev: Define the Derived Structures, Up: Deriving a New Hash Table Type Write the derived creation routine .................................. You must write a routine which will create and initialize an entry in the hash table. This routine is passed as the function argument to `bfd_hash_table_init'. In order to permit other hash tables to be derived from the hash table you are creating, this routine must be written in a standard way. The first argument to the creation routine is a pointer to a hash table entry. This may be `NULL', in which case the routine should allocate the right amount of space. Otherwise the space has already been allocated by a hash table type derived from this one. After allocating space, the creation routine must call the creation routine of the hash table type it is derived from, passing in a pointer to the space it just allocated. This will initialize any fields used by the base hash table. Finally the creation routine must initialize any local fields for the new hash table type. Here is a boilerplate example of a creation routine. FUNCTION_NAME is the name of the routine. ENTRY_TYPE is the type of an entry in the hash table you are creating. BASE_NEWFUNC is the name of the creation routine of the hash table type your hash table is derived from. struct bfd_hash_entry * FUNCTION_NAME (entry, table, string) struct bfd_hash_entry *entry; struct bfd_hash_table *table; const char *string; { struct ENTRY_TYPE *ret = (ENTRY_TYPE *) entry; /* Allocate the structure if it has not already been allocated by a derived class. */ if (ret == (ENTRY_TYPE *) NULL) { ret = ((ENTRY_TYPE *) bfd_hash_allocate (table, sizeof (ENTRY_TYPE))); if (ret == (ENTRY_TYPE *) NULL) return NULL; } /* Call the allocation method of the base class. */ ret = ((ENTRY_TYPE *) BASE_NEWFUNC ((struct bfd_hash_entry *) ret, table, string)); /* Initialize the local fields here. */ return (struct bfd_hash_entry *) ret; } *Description* The creation routine for the linker hash table, which is in `linker.c', looks just like this example. FUNCTION_NAME is `_bfd_link_hash_newfunc'. ENTRY_TYPE is `struct bfd_link_hash_entry'. BASE_NEWFUNC is `bfd_hash_newfunc', the creation routine for a basic hash table. `_bfd_link_hash_newfunc' also initializes the local fields in a linker hash table entry: `type', `written' and `next'.  File: bfd.info, Node: Write Other Derived Routines, Prev: Write the Derived Creation Routine, Up: Deriving a New Hash Table Type Write other derived routines ............................ You will want to write other routines for your new hash table, as well. You will want an initialization routine which calls the initialization routine of the hash table you are deriving from and initializes any other local fields. For the linker hash table, this is `_bfd_link_hash_table_init' in `linker.c'. You will want a lookup routine which calls the lookup routine of the hash table you are deriving from and casts the result. The linker hash table uses `bfd_link_hash_lookup' in `linker.c' (this actually takes an additional argument which it uses to decide how to return the looked up value). You may want a traversal routine. This should just call the traversal routine of the hash table you are deriving from with appropriate casts. The linker hash table uses `bfd_link_hash_traverse' in `linker.c'. These routines may simply be defined as macros. For example, the a.out backend linker hash table, which is derived from the linker hash table, uses macros for the lookup and traversal routines. These are `aout_link_hash_lookup' and `aout_link_hash_traverse' in aoutx.h.  File: bfd.info, Node: BFD back ends, Next: GNU Free Documentation License, Prev: BFD front end, Up: Top BFD back ends ************* * Menu: * What to Put Where:: * aout :: a.out backends * coff :: coff backends * elf :: elf backends * mmo :: mmo backend  File: bfd.info, Node: What to Put Where, Next: aout, Prev: BFD back ends, Up: BFD back ends All of BFD lives in one directory.  File: bfd.info, Node: aout, Next: coff, Prev: What to Put Where, Up: BFD back ends a.out backends ============== *Description* BFD supports a number of different flavours of a.out format, though the major differences are only the sizes of the structures on disk, and the shape of the relocation information. The support is split into a basic support file `aoutx.h' and other files which derive functions from the base. One derivation file is `aoutf1.h' (for a.out flavour 1), and adds to the basic a.out functions support for sun3, sun4, 386 and 29k a.out files, to create a target jump vector for a specific target. This information is further split out into more specific files for each machine, including `sunos.c' for sun3 and sun4, `newsos3.c' for the Sony NEWS, and `demo64.c' for a demonstration of a 64 bit a.out format. The base file `aoutx.h' defines general mechanisms for reading and writing records to and from disk and various other methods which BFD requires. It is included by `aout32.c' and `aout64.c' to form the names `aout_32_swap_exec_header_in', `aout_64_swap_exec_header_in', etc. As an example, this is what goes on to make the back end for a sun4, from `aout32.c': #define ARCH_SIZE 32 #include "aoutx.h" Which exports names: ... aout_32_canonicalize_reloc aout_32_find_nearest_line aout_32_get_lineno aout_32_get_reloc_upper_bound ... from `sunos.c': #define TARGET_NAME "a.out-sunos-big" #define VECNAME sunos_big_vec #include "aoutf1.h" requires all the names from `aout32.c', and produces the jump vector sunos_big_vec The file `host-aout.c' is a special case. It is for a large set of hosts that use "more or less standard" a.out files, and for which cross-debugging is not interesting. It uses the standard 32-bit a.out support routines, but determines the file offsets and addresses of the text, data, and BSS sections, the machine architecture and machine type, and the entry point address, in a host-dependent manner. Once these values have been determined, generic code is used to handle the object file. When porting it to run on a new system, you must supply: HOST_PAGE_SIZE HOST_SEGMENT_SIZE HOST_MACHINE_ARCH (optional) HOST_MACHINE_MACHINE (optional) HOST_TEXT_START_ADDR HOST_STACK_END_ADDR in the file `../include/sys/h-XXX.h' (for your host). These values, plus the structures and macros defined in `a.out.h' on your host system, will produce a BFD target that will access ordinary a.out files on your host. To configure a new machine to use `host-aout.c', specify: TDEFAULTS = -DDEFAULT_VECTOR=host_aout_big_vec TDEPFILES= host-aout.o trad-core.o in the `config/XXX.mt' file, and modify `configure.in' to use the `XXX.mt' file (by setting "`bfd_target=XXX'") when your configuration is selected. Relocations ----------- *Description* The file `aoutx.h' provides for both the _standard_ and _extended_ forms of a.out relocation records. The standard records contain only an address, a symbol index, and a type field. The extended records (used on 29ks and sparcs) also have a full integer for an addend. Internal entry points --------------------- *Description* `aoutx.h' exports several routines for accessing the contents of an a.out file, which are gathered and exported in turn by various format specific files (eg sunos.c). `aout_SIZE_swap_exec_header_in' ............................... *Synopsis* void aout_SIZE_swap_exec_header_in, (bfd *abfd, struct external_exec *raw_bytes, struct internal_exec *execp); *Description* Swap the information in an executable header RAW_BYTES taken from a raw byte stream memory image into the internal exec header structure EXECP. `aout_SIZE_swap_exec_header_out' ................................ *Synopsis* void aout_SIZE_swap_exec_header_out (bfd *abfd, struct internal_exec *execp, struct external_exec *raw_bytes); *Description* Swap the information in an internal exec header structure EXECP into the buffer RAW_BYTES ready for writing to disk. `aout_SIZE_some_aout_object_p' .............................. *Synopsis* const bfd_target *aout_SIZE_some_aout_object_p (bfd *abfd, const bfd_target *(*callback_to_real_object_p) ()); *Description* Some a.out variant thinks that the file open in ABFD checking is an a.out file. Do some more checking, and set up for access if it really is. Call back to the calling environment's "finish up" function just before returning, to handle any last-minute setup. `aout_SIZE_mkobject' .................... *Synopsis* boolean aout_SIZE_mkobject, (bfd *abfd); *Description* Initialize BFD ABFD for use with a.out files. `aout_SIZE_machine_type' ........................ *Synopsis* enum machine_type aout_SIZE_machine_type (enum bfd_architecture arch, unsigned long machine)); *Description* Keep track of machine architecture and machine type for a.out's. Return the `machine_type' for a particular architecture and machine, or `M_UNKNOWN' if that exact architecture and machine can't be represented in a.out format. If the architecture is understood, machine type 0 (default) is always understood. `aout_SIZE_set_arch_mach' ......................... *Synopsis* boolean aout_SIZE_set_arch_mach, (bfd *, enum bfd_architecture arch, unsigned long machine)); *Description* Set the architecture and the machine of the BFD ABFD to the values ARCH and MACHINE. Verify that ABFD's format can support the architecture required. `aout_SIZE_new_section_hook' ............................ *Synopsis* boolean aout_SIZE_new_section_hook, (bfd *abfd, asection *newsect)); *Description* Called by the BFD in response to a `bfd_make_section' request.