]> BFD Internals bfd internals This document describes some BFD internal information which may be helpful when working on BFD. It is very incomplete. This document is not updated regularly, and may be out of date. The initial version of this document was written by Ian Lance Taylor . BFD overview BFD is a library which provides a single interface to read and write object files, executables, archive files, and core files in any format. BFD library interfaces One way to look at the BFD library is to divide it into four parts by type of interface. The first interface is the set of generic functions which programs using the BFD library will call. These generic function normally translate directly or indirectly into calls to routines which are specific to a particular object file format. Many of these generic functions are actually defined as macros in bfd.h. These functions comprise the official BFD interface. The second interface is the set of functions which appear in the target vectors. This is the bulk of the code in BFD. A target vector is a set of function pointers specific to a particular object file format. The target vector is used to implement the generic BFD functions. These functions are always called through the target vector, and are never called directly. The target vector is described in detail in . The set of functions which appear in a particular target vector is often referred to as a BFD backend. The third interface is a set of oddball functions which are typically specific to a particular object file format, are not generic functions, and are called from outside of the BFD library. These are used as hooks by the linker and the assembler when a particular object file format requires some action which the BFD generic interface does not provide. These functions are typically declared in bfd.h, but in many cases they are only provided when BFD is configured with support for a particular object file format. These functions live in a grey area, and are not really part of the official BFD interface. The fourth interface is the set of BFD support functions which are called by the other BFD functions. These manage issues like memory allocation, error handling, file access, hash tables, swapping, and the like. These functions are never called from outside of the BFD library. BFD library users Another way to look at the BFD library is to divide it into three parts by the manner in which it is used. The first use is to read an object file. The object file readers are programs like ‘gdb’, ‘nm’, ‘objdump’, and ‘objcopy’. These programs use BFD to view an object file in a generic form. The official BFD interface is normally fully adequate for these programs. The second use is to write an object file. The object file writers are programs like ‘gas’ and ‘objcopy’. These programs use BFD to create an object file. The official BFD interface is normally adequate for these programs, but for some object file formats the assembler needs some additional hooks in order to set particular flags or other information. The official BFD interface includes functions to copy private information from one object file to another, and these functions are used by ‘objcopy’ to avoid information loss. The third use is to link object files. There is only one object file linker, ‘ld’. Originally, ‘ld’ was an object file reader and an object file writer, and it did the link operation using the generic BFD structures. However, this turned out to be too slow and too memory intensive. The official BFD linker functions were written to permit specific BFD backends to perform the link without translating through the generic structures, in the normal case where all the input files and output file have the same object file format. Not all of the backends currently implement the new interface, and there are default linking functions within BFD which use the generic structures and which work with all backends. For several object file formats the linker needs additional hooks which are not provided by the official BFD interface, particularly for dynamic linking support. These functions are typically called from the linker emulation template. The BFD view of a file BFD uses generic structures to manage information. It translates data into the generic form when reading files, and out of the generic form when writing files. BFD describes a file as a pointer to the ‘bfd’ type. A ‘bfd’ is composed of the following elements. The BFD information can be displayed using the ‘objdump’ program with various options. general information The object file format, a few general flags, the start address. architecture The architecture, including both a general processor type (m68k, MIPSetc.) and a specific machine number (m68000, R4000, etc.). sections A list of sections. symbols A symbol table. BFD represents a section as a pointer to the ‘asection’ type. Each section has a name and a size. Most sections also have an associated block of data, known as the section contents. Sections also have associated flags, a virtual memory address, a load memory address, a required alignment, a list of relocations, and other miscellaneous information. BFD represents a relocation as a pointer to the ‘arelent’ type. A relocation describes an action which the linker must take to modify the section contents. Relocations have a symbol, an address, an addend, and a pointer to a howto structure which describes how to perform the relocation. For more information, see . BFD represents a symbol as a pointer to the ‘asymbol’ type. A symbol has a name, a pointer to a section, an offset within that section, and some flags. Archive files do not have any sections or symbols. Instead, BFD represents an archive file as a file which contains a list of ‘bfd’s. BFD also provides access to the archive symbol map, as a list of symbol names. BFD provides a function to return the ‘bfd’ within the archive which corresponds to a particular entry in the archive symbol map. BFD loses information Most object file formats have information which BFD can not represent in its generic form, at least as currently defined. There is often explicit information which BFD can not represent. For example, the COFF version stamp, or the ELF program segments. BFD provides special hooks to handle this information when copying, printing, or linking an object file. The BFD support for a particular object file format will normally store this information in private data and handle it using the special hooks. In some cases there is also implicit information which BFD can not represent. For example, the MIPS processor distinguishes small and large symbols, and requires that all small symbols be within 32K of the GP register. This means that the MIPS assembler must be able to mark variables as either small or large, and the MIPS linker must know to put small symbols within range of the GP register. Since BFD can not represent this information, this means that the assembler and linker must have information that is specific to a particular object file format which is outside of the BFD library. This loss of information indicates areas where the BFD paradigm breaks down. It is not actually possible to represent the myriad differences among object file formats using a single generic interface, at least not in the manner which BFD does it today. Nevertheless, the BFD library does greatly simplify the task of dealing with object files, and particular problems caused by information loss can normally be solved using some sort of relatively constrained hook into the library. BFD programming guidelines bfd programming guidelines programming guidelines for bfd guidelines, bfd programming There is a lot of poorly written and confusing code in BFD. New BFD code should be written to a higher standard. Merely because some BFD code is written in a particular manner does not mean that you should emulate it. Here are some general BFD programming guidelines: Follow the GNU coding standards. Avoid global variables. We ideally want BFD to be fully reentrant, sothat it can be used in multiple threads. All uses of global or staticvariables interfere with that. Initialized constant variables are OK,and they should be explicitly marked with ‘const’. Instead of globalvariables, use data attached to a BFD or to a linker hash table. All externally visible functions should have names which start with‘bfd_’. All such functions should be declared in some header file,typically bfd.h. See, for example, the various declarations nearthe end of bfd-in.h, which mostly declare functions required byspecific linker emulations. All functions which need to be visible from one file to another withinBFD, but should not be visible outside of BFD, should start with‘_bfd_’. Although external names beginning with ‘_’ areprohibited by the ANSI standard, in practice this usage will alwayswork, and it is required by the GNU coding standards. Always remember that people can compile using ‘--enable-targets’ tobuild several, or all, targets at once. It must be possible to linktogether the files for all targets. BFD code should compile with few or no warnings using ‘gcc -Wall’.Some warnings are OK, like the absence of certain function declarationswhich may or may not be declared in system header files. Warnings aboutambiguous expressions and the like should always be fixed. BFD target vector bfd target vector target vector in bfd BFD supports multiple object file formats by using the target vector. This is simply a set of function pointers which implement behaviour that is specific to a particular object file format. In this section I list all of the entries in the target vector and describe what they do. Miscellaneous constants The target vector starts with a set of constants. ‘name’ The name of the target vector. This is an arbitrary string. This ishow the target vector is named in command line options for tools whichuse BFD, such as the ‘--oformat’ linker option. ‘flavour’ A general description of the type of target. The following flavours arecurrently defined: ‘bfd_target_unknown_flavour’ Undefined or unknown. ‘bfd_target_aout_flavour’ a.out. ‘bfd_target_coff_flavour’ COFF. ‘bfd_target_ecoff_flavour’ ECOFF. ‘bfd_target_elf_flavour’ ELF. ‘bfd_target_ieee_flavour’ IEEE-695. ‘bfd_target_nlm_flavour’ NLM. ‘bfd_target_oasys_flavour’ OASYS. ‘bfd_target_tekhex_flavour’ Tektronix hex format. ‘bfd_target_srec_flavour’ Motorola S-record format. ‘bfd_target_ihex_flavour’ Intel hex format. ‘bfd_target_som_flavour’ SOM (used on HP/UX). ‘bfd_target_os9k_flavour’ os9000. ‘bfd_target_versados_flavour’ VERSAdos. ‘bfd_target_msdos_flavour’ MS-DOS. ‘bfd_target_evax_flavour’ openVMS. ‘bfd_target_mmo_flavour’ Donald Knuth's MMIXware object format. ‘byteorder’ The byte order of data in the object file. One of‘BFD_ENDIAN_BIG’, ‘BFD_ENDIAN_LITTLE’, or‘BFD_ENDIAN_UNKNOWN’. The latter would be used for a format suchas S-records which do not record the architecture of the data. ‘header_byteorder’ The byte order of header information in the object file. Normally thesame as the ‘byteorder’ field, but there are certain cases where itmay be different. ‘object_flags’ Flags which may appear in the ‘flags’ field of a BFD with thisformat. ‘section_flags’ Flags which may appear in the ‘flags’ field of a section within aBFD with this format. ‘symbol_leading_char’ A character which the C compiler normally puts before a symbol. Forexample, an a.out compiler will typically generate the symbol‘_foo’ for a function named ‘foo’ in the C source, in whichcase this field would be ‘_’. If there is no such character, thisfield will be ‘0’. ‘ar_pad_char’ The padding character to use at the end of an archive name. Normally‘/’. ‘ar_max_namelen’ The maximum length of a short name in an archive. Normally ‘14’. ‘backend_data’ A pointer to constant backend data. This is used by backends to storewhatever additional information they need to distinguish similar targetvectors which use the same sets of functions. Swapping functions Every target vector has function pointers used for swapping information in and out of the target representation. There are two sets of functions: one for data information, and one for header information. Each set has three sizes: 64-bit, 32-bit, and 16-bit. Each size has three actual functions: put, get unsigned, and get signed. These 18 functions are used to convert data between the host and target representations. Format type dependent functions Every target vector has three arrays of function pointers which are indexed by the BFD format type. The BFD format types are as follows: ‘bfd_unknown’ Unknown format. Not used for anything useful. ‘bfd_object’ Object file. ‘bfd_archive’ Archive file. ‘bfd_core’ Core file. The three arrays of function pointers are as follows: ‘bfd_check_format’ Check whether the BFD is of a particular format (object file, archivefile, or core file) corresponding to this target vector. This is calledby the ‘bfd_check_format’ function when examining an existing BFD.If the BFD matches the desired format, this function will initialize anyformat specific information such as the ‘tdata’ field of the BFD.This function must be called before any other BFD target vector functionon a file opened for reading. ‘bfd_set_format’ Set the format of a BFD which was created for output. This is called bythe ‘bfd_set_format’ function after creating the BFD with afunction such as ‘bfd_openw’. This function will initialize formatspecific information required to write out an object file or whatever ofthe given format. This function must be called before any other BFDtarget vector function on a file opened for writing. ‘bfd_write_contents’ Write out the contents of the BFD in the given format. This is calledby ‘bfd_close’ function for a BFD opened for writing. This reallyshould not be an array selected by format type, as the‘bfd_set_format’ function provides all the required information.In fact, BFD will fail if a different format is used when callingthrough the ‘bfd_set_format’ and the ‘bfd_write_contents’arrays; fortunately, since ‘bfd_close’ gets it right, this is adifficult error to make. ‘BFD_JUMP_TABLE’ macros ‘BFD_JUMP_TABLE’ Most target vectors are defined using ‘BFD_JUMP_TABLE’ macros. These macros take a single argument, which is a prefix applied to a set of functions. The macros are then used to initialize the fields in the target vector. For example, the ‘BFD_JUMP_TABLE_RELOCS’ macro defines three functions: ‘_get_reloc_upper_bound’, ‘_canonicalize_reloc’, and ‘_bfd_reloc_type_lookup’. A reference like ‘BFD_JUMP_TABLE_RELOCS (foo)’ will expand into three functions prefixed with ‘foo’: ‘foo_get_reloc_upper_bound’, etc. The ‘BFD_JUMP_TABLE_RELOCS’ macro will be placed such that those three functions initialize the appropriate fields in the BFD target vector. This is done because it turns out that many different target vectors can share certain classes of functions. For example, archives are similar on most platforms, so most target vectors can use the same archive functions. Those target vectors all use ‘BFD_JUMP_TABLE_ARCHIVE’ with the same argument, calling a set of functions which is defined in archive.c. Each of the ‘BFD_JUMP_TABLE’ macros is mentioned below along with the description of the function pointers which it defines. The function pointers will be described using the name without the prefix which the ‘BFD_JUMP_TABLE’ macro defines. This name is normally the same as the name of the field in the target vector structure. Any differences will be noted. Generic functions ‘BFD_JUMP_TABLE_GENERIC’ The ‘BFD_JUMP_TABLE_GENERIC’ macro is used for some catch all functions which don't easily fit into other categories. ‘_close_and_cleanup’ Free any target specific information associated with the BFD. This iscalled when any BFD is closed (the ‘bfd_write_contents’ functionmentioned earlier is only called for a BFD opened for writing). Mosttargets use ‘bfd_alloc’ to allocate all target specificinformation, and therefore don't have to do anything in this function.This function pointer is typically set to‘_bfd_generic_close_and_cleanup’, which simply returns true. ‘_bfd_free_cached_info’ Free any cached information associated with the BFD which can berecreated later if necessary. This is used to reduce the memoryconsumption required by programs using BFD. This is normally called viathe ‘bfd_free_cached_info’ macro. It is used by the defaultarchive routines when computing the archive map. Most targets do notdo anything special for this entry point, and just set it to‘_bfd_generic_free_cached_info’, which simply returns true. ‘_new_section_hook’ This is called from ‘bfd_make_section_anyway’ whenever a newsection is created. Most targets use it to initialize section specificinformation. This function is called whether or not the sectioncorresponds to an actual section in an actual BFD. ‘_get_section_contents’ Get the contents of a section. This is called from‘bfd_get_section_contents’. Most targets set this to‘_bfd_generic_get_section_contents’, which does a ‘bfd_seek’based on the section's ‘filepos’ field and a ‘bfd_bread’. Thecorresponding field in the target vector is named‘_bfd_get_section_contents’. ‘_get_section_contents_in_window’ Set a ‘bfd_window’ to hold the contents of a section. This iscalled from ‘bfd_get_section_contents_in_window’. The‘bfd_window’ idea never really caught on, and I don't think this isever called. Pretty much all targets implement this as‘bfd_generic_get_section_contents_in_window’, which uses‘bfd_get_section_contents’ to do the right thing. Thecorresponding field in the target vector is named‘_bfd_get_section_contents_in_window’. Copy functions ‘BFD_JUMP_TABLE_COPY’ The ‘BFD_JUMP_TABLE_COPY’ macro is used for functions which are called when copying BFDs, and for a couple of functions which deal with internal BFD information. ‘_bfd_copy_private_bfd_data’ This is called when copying a BFD, via ‘bfd_copy_private_bfd_data’.If the input and output BFDs have the same format, this will copy anyprivate information over. This is called after all the section contentshave been written to the output file. Only a few targets do anything inthis function. ‘_bfd_merge_private_bfd_data’ This is called when linking, via ‘bfd_merge_private_bfd_data’. Itgives the backend linker code a chance to set any special flags in theoutput file based on the contents of the input file. Only a few targetsdo anything in this function. ‘_bfd_copy_private_section_data’ This is similar to ‘_bfd_copy_private_bfd_data’, but it is calledfor each section, via ‘bfd_copy_private_section_data’. Thisfunction is called before any section contents have been written. Onlya few targets do anything in this function. ‘_bfd_copy_private_symbol_data’ This is called via ‘bfd_copy_private_symbol_data’, but I don'tthink anything actually calls it. If it were defined, it could be usedto copy private symbol data from one BFD to another. However, most BFDsstore extra symbol information by allocating space which is larger thanthe ‘asymbol’ structure and storing private information in theextra space. Since ‘objcopy’ and other programs copy symbolinformation by copying pointers to ‘asymbol’ structures, theprivate symbol information is automatically copied as well. Mosttargets do not do anything in this function. ‘_bfd_set_private_flags’ This is called via ‘bfd_set_private_flags’. It is basically a hookfor the assembler to set magic information. For example, the PowerPCELF assembler uses it to set flags which appear in the e_flags field ofthe ELF header. Most targets do not do anything in this function. ‘_bfd_print_private_bfd_data’ This is called by ‘objdump’ when the ‘-p’ option is used. Itis called via ‘bfd_print_private_data’. It prints any interestinginformation about the BFD which can not be otherwise represented by BFDand thus can not be printed by ‘objdump’. Most targets do not doanything in this function. Core file support functions ‘BFD_JUMP_TABLE_CORE’ The ‘BFD_JUMP_TABLE_CORE’ macro is used for functions which deal with core files. Obviously, these functions only do something interesting for targets which have core file support. ‘_core_file_failing_command’ Given a core file, this returns the command which was run to produce thecore file. ‘_core_file_failing_signal’ Given a core file, this returns the signal number which produced thecore file. ‘_core_file_matches_executable_p’ Given a core file and a BFD for an executable, this returns whether thecore file was generated by the executable. Archive functions ‘BFD_JUMP_TABLE_ARCHIVE’ The ‘BFD_JUMP_TABLE_ARCHIVE’ macro is used for functions which deal with archive files. Most targets use COFF style archive files (including ELF targets), and these use ‘_bfd_archive_coff’ as the argument to ‘BFD_JUMP_TABLE_ARCHIVE’. Some targets use BSD/a.out style archives, and these use ‘_bfd_archive_bsd’. (The main difference between BSD and COFF archives is the format of the archive symbol table). Targets with no archive support use ‘_bfd_noarchive’. Finally, a few targets have unusual archive handling. ‘_slurp_armap’ Read in the archive symbol table, storing it in private BFD data. Thisis normally called from the archive ‘check_format’ routine. Thecorresponding field in the target vector is named‘_bfd_slurp_armap’. ‘_slurp_extended_name_table’ Read in the extended name table from the archive, if there is one,storing it in private BFD data. This is normally called from thearchive ‘check_format’ routine. The corresponding field in thetarget vector is named ‘_bfd_slurp_extended_name_table’. ‘construct_extended_name_table’ Build and return an extended name table if one is needed to write outthe archive. This also adjusts the archive headers to refer to theextended name table appropriately. This is normally called from thearchive ‘write_contents’ routine. The corresponding field in thetarget vector is named ‘_bfd_construct_extended_name_table’. ‘_truncate_arname’ This copies a file name into an archive header, truncating it asrequired. It is normally called from the archive ‘write_contents’routine. This function is more interesting in targets which do notsupport extended name tables, but I think the GNU ‘ar’ programalways uses extended name tables anyhow. The corresponding field in thetarget vector is named ‘_bfd_truncate_arname’. ‘_write_armap’ Write out the archive symbol table using calls to ‘bfd_bwrite’.This is normally called from the archive ‘write_contents’ routine.The corresponding field in the target vector is named ‘write_armap’(no leading underscore). ‘_read_ar_hdr’ Read and parse an archive header. This handles expanding the archiveheader name into the real file name using the extended name table. Thisis called by routines which read the archive symbol table or the archiveitself. The corresponding field in the target vector is named‘_bfd_read_ar_hdr_fn’. ‘_openr_next_archived_file’ Given an archive and a BFD representing a file stored within thearchive, return a BFD for the next file in the archive. This is calledvia ‘bfd_openr_next_archived_file’. The corresponding field in thetarget vector is named ‘openr_next_archived_file’ (no leadingunderscore). ‘_get_elt_at_index’ Given an archive and an index, return a BFD for the file in the archivecorresponding to that entry in the archive symbol table. This is calledvia ‘bfd_get_elt_at_index’. The corresponding field in the targetvector is named ‘_bfd_get_elt_at_index’. ‘_generic_stat_arch_elt’ Do a stat on an element of an archive, returning information read fromthe archive header (modification time, uid, gid, file mode, size). Thisis called via ‘bfd_stat_arch_elt’. The corresponding field in thetarget vector is named ‘_bfd_stat_arch_elt’. ‘_update_armap_timestamp’ After the entire contents of an archive have been written out, updatethe timestamp of the archive symbol table to be newer than that of thefile. This is required for a.out style archives. This is normallycalled by the archive ‘write_contents’ routine. The correspondingfield in the target vector is named ‘_bfd_update_armap_timestamp’. Symbol table functions ‘BFD_JUMP_TABLE_SYMBOLS’ The ‘BFD_JUMP_TABLE_SYMBOLS’ macro is used for functions which deal with symbols. ‘_get_symtab_upper_bound’ Return a sensible upper bound on the amount of memory which will berequired to read the symbol table. In practice most targets return theamount of memory required to hold ‘asymbol’ pointers for all thesymbols plus a trailing ‘NULL’ entry, and store the actual symbolinformation in BFD private data. This is called via‘bfd_get_symtab_upper_bound’. The corresponding field in thetarget vector is named ‘_bfd_get_symtab_upper_bound’. ‘_canonicalize_symtab’ Read in the symbol table. This is called via‘bfd_canonicalize_symtab’. The corresponding field in the targetvector is named ‘_bfd_canonicalize_symtab’. ‘_make_empty_symbol’ Create an empty symbol for the BFD. This is needed because most targetsstore extra information with each symbol by allocating a structurelarger than an ‘asymbol’ and storing the extra information at theend. This function will allocate the right amount of memory, and returnwhat looks like a pointer to an empty ‘asymbol’. This is calledvia ‘bfd_make_empty_symbol’. The corresponding field in the targetvector is named ‘_bfd_make_empty_symbol’. ‘_print_symbol’ Print information about the symbol. This is called via‘bfd_print_symbol’. One of the arguments indicates what sort ofinformation should be printed: ‘bfd_print_symbol_name’ Just print the symbol name. ‘bfd_print_symbol_more’ Print the symbol name and some interesting flags. I don't thinkanything actually uses this. ‘bfd_print_symbol_all’ Print all information about the symbol. This is used by ‘objdump’when run with the ‘-t’ option. The corresponding field in the target vector is named‘_bfd_print_symbol’. ‘_get_symbol_info’ Return a standard set of information about the symbol. This is calledvia ‘bfd_symbol_info’. The corresponding field in the targetvector is named ‘_bfd_get_symbol_info’. ‘_bfd_is_local_label_name’ Return whether the given string would normally represent the name of alocal label. This is called via ‘bfd_is_local_label’ and‘bfd_is_local_label_name’. Local labels are normally discarded bythe assembler. In the linker, this defines the difference between the‘-x’ and ‘-X’ options. ‘_get_lineno’ Return line number information for a symbol. This is only meaningfulfor a COFF target. This is called when writing out COFF line numbers. ‘_find_nearest_line’ Given an address within a section, use the debugging information to findthe matching file name, function name, and line number, if any. This iscalled via ‘bfd_find_nearest_line’. The corresponding field in thetarget vector is named ‘_bfd_find_nearest_line’. ‘_bfd_make_debug_symbol’ Make a debugging symbol. This is only meaningful for a COFF target,where it simply returns a symbol which will be placed in the‘N_DEBUG’ section when it is written out. This is called via‘bfd_make_debug_symbol’. ‘_read_minisymbols’ Minisymbols are used to reduce the memory requirements of programs like‘nm’. A minisymbol is a cookie pointing to internal symbolinformation which the caller can use to extract complete symbolinformation. This permits BFD to not convert all the symbols intogeneric form, but to instead convert them one at a time. This is calledvia ‘bfd_read_minisymbols’. Most targets do not implement this,and just use generic support which is based on using standard‘asymbol’ structures. ‘_minisymbol_to_symbol’ Convert a minisymbol to a standard ‘asymbol’. This is called via‘bfd_minisymbol_to_symbol’. Relocation support ‘BFD_JUMP_TABLE_RELOCS’ The ‘BFD_JUMP_TABLE_RELOCS’ macro is used for functions which deal with relocations. ‘_get_reloc_upper_bound’ Return a sensible upper bound on the amount of memory which will berequired to read the relocations for a section. In practice mosttargets return the amount of memory required to hold ‘arelent’pointers for all the relocations plus a trailing ‘NULL’ entry, andstore the actual relocation information in BFD private data. This iscalled via ‘bfd_get_reloc_upper_bound’. ‘_canonicalize_reloc’ Return the relocation information for a section. This is called via‘bfd_canonicalize_reloc’. The corresponding field in the targetvector is named ‘_bfd_canonicalize_reloc’. ‘_bfd_reloc_type_lookup’ Given a relocation code, return the corresponding howto structure(see ). This is called via‘bfd_reloc_type_lookup’. The corresponding field in the targetvector is named ‘reloc_type_lookup’. Output functions ‘BFD_JUMP_TABLE_WRITE’ The ‘BFD_JUMP_TABLE_WRITE’ macro is used for functions which deal with writing out a BFD. ‘_set_arch_mach’ Set the architecture and machine number for a BFD. This is called via‘bfd_set_arch_mach’. Most targets implement this by calling‘bfd_default_set_arch_mach’. The corresponding field in the targetvector is named ‘_bfd_set_arch_mach’. ‘_set_section_contents’ Write out the contents of a section. This is called via‘bfd_set_section_contents’. The corresponding field in the targetvector is named ‘_bfd_set_section_contents’. Linker functions ‘BFD_JUMP_TABLE_LINK’ The ‘BFD_JUMP_TABLE_LINK’ macro is used for functions called by the linker. ‘_sizeof_headers’ Return the size of the header information required for a BFD. This isused to implement the ‘SIZEOF_HEADERS’ linker script function. Itis normally used to align the first section at an efficient position onthe page. This is called via ‘bfd_sizeof_headers’. Thecorresponding field in the target vector is named‘_bfd_sizeof_headers’. ‘_bfd_get_relocated_section_contents’ Read the contents of a section and apply the relocation information.This handles both a final link and a relocatable link; in the lattercase, it adjust the relocation information as well. This is called via‘bfd_get_relocated_section_contents’. Most targets implement it bycalling ‘bfd_generic_get_relocated_section_contents’. ‘_bfd_relax_section’ Try to use relaxation to shrink the size of a section. This is calledby the linker when the ‘-relax’ option is used. This is called via‘bfd_relax_section’. Most targets do not support any sort ofrelaxation. ‘_bfd_link_hash_table_create’ Create the symbol hash table to use for the linker. This linker hookpermits the backend to control the size and information of the elementsin the linker symbol hash table. This is called via‘bfd_link_hash_table_create’. ‘_bfd_link_add_symbols’ Given an object file or an archive, add all symbols into the linkersymbol hash table. Use callbacks to the linker to include archiveelements in the link. This is called via ‘bfd_link_add_symbols’. ‘_bfd_final_link’ Finish the linking process. The linker calls this hook after all of theinput files have been read, when it is ready to finish the link andgenerate the output file. This is called via ‘bfd_final_link’. ‘_bfd_link_split_section’ I don't know what this is for. Nothing seems to call it. The onlynon-trivial definition is in som.c. Dynamic linking information functions ‘BFD_JUMP_TABLE_DYNAMIC’ The ‘BFD_JUMP_TABLE_DYNAMIC’ macro is used for functions which read dynamic linking information. ‘_get_dynamic_symtab_upper_bound’ Return a sensible upper bound on the amount of memory which will berequired to read the dynamic symbol table. In practice most targetsreturn the amount of memory required to hold ‘asymbol’ pointers forall the symbols plus a trailing ‘NULL’ entry, and store the actualsymbol information in BFD private data. This is called via‘bfd_get_dynamic_symtab_upper_bound’. The corresponding field inthe target vector is named ‘_bfd_get_dynamic_symtab_upper_bound’. ‘_canonicalize_dynamic_symtab’ Read the dynamic symbol table. This is called via‘bfd_canonicalize_dynamic_symtab’. The corresponding field in thetarget vector is named ‘_bfd_canonicalize_dynamic_symtab’. ‘_get_dynamic_reloc_upper_bound’ Return a sensible upper bound on the amount of memory which will berequired to read the dynamic relocations. In practice most targetsreturn the amount of memory required to hold ‘arelent’ pointers forall the relocations plus a trailing ‘NULL’ entry, and store theactual relocation information in BFD private data. This is called via‘bfd_get_dynamic_reloc_upper_bound’. The corresponding field inthe target vector is named ‘_bfd_get_dynamic_reloc_upper_bound’. ‘_canonicalize_dynamic_reloc’ Read the dynamic relocations. This is called via‘bfd_canonicalize_dynamic_reloc’. The corresponding field in thetarget vector is named ‘_bfd_canonicalize_dynamic_reloc’. BFD generated files generated files in bfd bfd generated files BFD contains several automatically generated files. This section describes them. Some files are created at configure time, when you configure BFD. Some files are created at make time, when you build BFD. Some files are automatically rebuilt at make time, but only if you configure with the ‘--enable-maintainer-mode’ option. Some files live in the object directory—the directory from which you run configure—and some live in the source directory. All files that live in the source directory are checked into the CVS repository. bfd.h bfd.h bfd-in3.hLives in the object directory. Created at make time frombfd-in2.h via bfd-in3.h. bfd-in3.h is created atconfigure time from bfd-in2.h. There are automatic dependenciesto rebuild bfd-in3.h and hence bfd.h if bfd-in2.hchanges, so you can normally ignore bfd-in3.h, and just thinkabout bfd-in2.h and bfd.h.bfd.h is built by replacing a few strings in bfd-in2.h.To see them, search for ‘@’ in bfd-in2.h. They mainlycontrol whether BFD is built for a 32 bit target or a 64 bit target. bfd-in2.h bfd-in2.hLives in the source directory. Created from bfd-in.h and severalother BFD source files. If you configure with the‘--enable-maintainer-mode’ option, bfd-in2.h is rebuiltautomatically when a source file changes. elf32-target.helf64-target.h elf32-target.h elf64-target.hLive in the object directory. Created from elfxx-target.h.These files are versions of elfxx-target.h customized for eithera 32 bit ELF target or a 64 bit ELF target. libbfd.h libbfd.hLives in the source directory. Created from libbfd-in.h andseveral other BFD source files. If you configure with the‘--enable-maintainer-mode’ option, libbfd.h is rebuiltautomatically when a source file changes. libcoff.h libcoff.hLives in the source directory. Created from libcoff-in.h andcoffcode.h. If you configure with the‘--enable-maintainer-mode’ option, libcoff.h is rebuiltautomatically when a source file changes. targmatch.h targmatch.hLives in the object directory. Created at make time fromconfig.bfd. This file is used to map configuration triplets intoBFD target vector variable names at run time. Files compiled multiple times in BFDSeveral files in BFD are compiled multiple times. By this I mean that there are header files which contain function definitions. These header files are included by other files, and thus the functions are compiled once per file which includes them. Preprocessor macros are used to control the compilation, so that each time the files are compiled the resulting functions are slightly different. Naturally, if they weren't different, there would be no reason to compile them multiple times. This is a not a particularly good programming technique, and future BFD work should avoid it. Since this technique is rarely used, even experienced C programmers findit confusing. It is difficult to debug programs which use BFD, since there is no wayto describe which version of a particular function you are looking at. Programs which use BFD wind up incorporating two or more slightlydifferent versions of the same function, which wastes space in theexecutable. This technique is never required nor is it especially efficient. It isalways possible to use statically initialized structures holdingfunction pointers and magic constants instead. The following is a list of the files which are compiled multiple times. aout-target.h aout-target.hDescribes a few functions and the target vector for a.out targets. Thisis used by individual a.out targets with different definitions of‘N_TXTADDR’ and similar a.out macros. aoutf1.h aoutf1.hImplements standard SunOS a.out files. In principle it supports 64 bita.out targets based on the preprocessor macro ‘ARCH_SIZE’, butsince all known a.out targets are 32 bits, this code may or may notwork. This file is only included by a few other files, and it isdifficult to justify its existence. aoutx.h aoutx.hImplements basic a.out support routines. This file can be compiled foreither 32 or 64 bit support. Since all known a.out targets are 32 bits,the 64 bit support may or may not work. I believe the originalintention was that this file would only be included by ‘aout32.c’and ‘aout64.c’, and that other a.out targets would simply refer tothe functions it defined. Unfortunately, some other a.out targetsstarted including it directly, leading to a somewhat confused state ofaffairs. coffcode.h coffcode.hImplements basic COFF support routines. This file is included by everyCOFF target. It implements code which handles COFF magic numbers aswell as various hook functions called by the generic COFF functions incoffgen.c. This file is controlled by a number of differentmacros, and more are added regularly. coffswap.h coffswap.hImplements COFF swapping routines. This file is included bycoffcode.h, and thus by every COFF target. It implements theroutines which swap COFF structures between internal and externalformat. The main control for this file is the external structuredefinitions in the files in the include/coff directory. A COFFtarget file will include one of those files before includingcoffcode.h and thus coffswap.h. There are a few othermacros which affect coffswap.h as well, mostly describing whethercertain fields are present in the external structures. ecoffswap.h ecoffswap.hImplements ECOFF swapping routines. This is like coffswap.h, butfor ECOFF. It is included by the ECOFF target files (of which there areonly two). The control is the preprocessor macro ‘ECOFF_32’ or‘ECOFF_64’. elfcode.h elfcode.hImplements ELF functions that use external structure definitions. Thisfile is included by two other files: elf32.c and elf64.c.It is controlled by the ‘ARCH_SIZE’ macro which is defined to be‘32’ or ‘64’ before including it. The ‘NAME’ macro isused internally to give the functions different names for the two targetsizes. elfcore.h elfcore.hLike elfcode.h, but for functions that are specific to ELF corefiles. This is included only by elfcode.h. elfxx-target.h elfxx-target.hThis file is the source for the generated files elf32-target.hand elf64-target.h, one of which is included by every ELF target.It defines the ELF target vector. freebsd.h freebsd.hPresumably intended to be included by all FreeBSD targets, but in factthere is only one such target, ‘i386-freebsd’. This defines afunction used to set the right magic number for FreeBSD, as well asvarious macros, and includes aout-target.h. netbsd.h netbsd.hLike freebsd.h, except that there are several files which includeit. nlm-target.h nlm-target.hDefines the target vector for a standard NLM target. nlmcode.h nlmcode.hLike elfcode.h, but for NLM targets. This is only included bynlm32.c and nlm64.c, both of which define the macro‘ARCH_SIZE’ to an appropriate value. There are no 64 bit NLMtargets anyhow, so this is sort of useless. nlmswap.h nlmswap.hLike coffswap.h, but for NLM targets. This is included by eachNLM target, but I think it winds up compiling to the exact same code forevery target, and as such is fairly useless. peicode.h peicode.hProvides swapping routines and other hooks for PE targets.coffcode.h will include this rather than coffswap.h for aPE target. This defines PE specific versions of the COFF swappingroutines, and also defines some macros which control coffcode.hitself. BFD relocation handling bfd relocation handling relocations in bfd The handling of relocations is one of the more confusing aspects of BFD. Relocation handling has been implemented in various different ways, all somewhat incompatible, none perfect. BFD relocation concepts A relocation is an action which the linker must take when linking. It describes a change to the contents of a section. The change is normally based on the final value of one or more symbols. Relocations are created by the assembler when it creates an object file. Most relocations are simple. A typical simple relocation is to set 32 bits at a given offset in a section to the value of a symbol. This type of relocation would be generated for code like int *p = &i; where ‘p’ and ‘i’ are global variables. A relocation for the symbol ‘i’ would be generated such that the linker would initialize the area of memory which holds the value of ‘p’ to the value of the symbol ‘i’. Slightly more complex relocations may include an addend, which is a constant to add to the symbol value before using it. In some cases a relocation will require adding the symbol value to the existing contents of the section in the object file. In others the relocation will simply replace the contents of the section with the symbol value. Some relocations are PC relative, so that the value to be stored in the section is the difference between the value of a symbol and the final address of the section contents. In general, relocations can be arbitrarily complex. For example, relocations used in dynamic linking systems often require the linker to allocate space in a different section and use the offset within that section as the value to store. In the IEEE object file format, relocations may involve arbitrary expressions. When doing a relocatable link, the linker may or may not have to do anything with a relocation, depending upon the definition of the relocation. Simple relocations generally do not require any special action. BFD relocation functions In BFD, each section has an array of ‘arelent’ structures. Each structure has a pointer to a symbol, an address within the section, an addend, and a pointer to a ‘reloc_howto_struct’ structure. The howto structure has a bunch of fields describing the reloc, including a type field. The type field is specific to the object file format backend; none of the generic code in BFD examines it. Originally, the function ‘bfd_perform_relocation’ was supposed to handle all relocations. In theory, many relocations would be simple enough to be described by the fields in the howto structure. For those that weren't, the howto structure included a ‘special_function’ field to use as an escape. While this seems plausible, a look at ‘bfd_perform_relocation’ shows that it failed. The function has odd special cases. Some of the fields in the howto structure, such as ‘pcrel_offset’, were not adequately documented. The linker uses ‘bfd_perform_relocation’ to do all relocations when the input and output file have different formats (e.g., when generating S-records). The generic linker code, which is used by all targets which do not define their own special purpose linker, uses ‘bfd_get_relocated_section_contents’, which for most targets turns into a call to ‘bfd_generic_get_relocated_section_contents’, which calls ‘bfd_perform_relocation’. So ‘bfd_perform_relocation’ is still widely used, which makes it difficult to change, since it is difficult to test all possible cases. The assembler used ‘bfd_perform_relocation’ for a while. This turned out to be the wrong thing to do, since ‘bfd_perform_relocation’ was written to handle relocations on an existing object file, while the assembler needed to create relocations in a new object file. The assembler was changed to use the new function ‘bfd_install_relocation’ instead, and ‘bfd_install_relocation’ was created as a copy of ‘bfd_perform_relocation’. Unfortunately, the work did not progress any farther, so ‘bfd_install_relocation’ remains a simple copy of ‘bfd_perform_relocation’, with all the odd special cases and confusing code. This again is difficult to change, because again any change can affect any assembler target, and so is difficult to test. The new linker, when using the same object file format for all input files and the output file, does not convert relocations into ‘arelent’ structures, so it can not use ‘bfd_perform_relocation’ at all. Instead, users of the new linker are expected to write a ‘relocate_section’ function which will handle relocations in a target specific fashion. There are two helper functions for target specific relocation: ‘_bfd_final_link_relocate’ and ‘_bfd_relocate_contents’. These functions use a howto structure, but they do not use the ‘special_function’ field. Since the functions are normally called from target specific code, the ‘special_function’ field adds little; any relocations which require special handling can be handled without calling those functions. So, if you want to add a new target, or add a new relocation to an existing target, you need to do the following: Make sure you clearly understand what the contents of the section shouldlook like after assembly, after a relocatable link, and after a finallink. Make sure you clearly understand the operations the linker mustperform during a relocatable link and during a final link. Write a howto structure for the relocation. The howto structure isflexible enough to represent any relocation which should be handled bysetting a contiguous bitfield in the destination to the value of asymbol, possibly with an addend, possibly adding the symbol value to thevalue already present in the destination. Change the assembler to generate your relocation. The assembler willcall ‘bfd_install_relocation’, so your howto structure has to beable to handle that. You may need to set the ‘special_function’field to handle assembly correctly. Be careful to ensure that any codeyou write to handle the assembler will also work correctly when doing arelocatable link. For example, see ‘bfd_elf_generic_reloc’. Test the assembler. Consider the cases of relocation against anundefined symbol, a common symbol, a symbol defined in the object filein the same section, and a symbol defined in the object file in adifferent section. These cases may not all be applicable for yourreloc. If your target uses the new linker, which is recommended, add anyrequired handling to the target specific relocation function. In simplecases this will just involve a call to ‘_bfd_final_link_relocate’or ‘_bfd_relocate_contents’, depending upon the definition of therelocation and whether the link is relocatable or not. Test the linker. Test the case of a final link. If the relocation canoverflow, use a linker script to force an overflow and make sure theerror is reported correctly. Test a relocatable link, whether thesymbol is defined or undefined in the relocatable output. For both thefinal and relocatable link, test the case when the symbol is a commonsymbol, when the symbol looked like a common symbol but became a definedsymbol, when the symbol is defined in a different object file, and whenthe symbol is defined in the same object file. In order for linking to another object file format, such as S-records,to work correctly, ‘bfd_perform_relocation’ has to do the rightthing for the relocation. You may need to set the‘special_function’ field to handle this correctly. Test this bydoing a link in which the output object file format is S-records. Using the linker to generate relocatable output in a different objectfile format is impossible in the general case, so you generally don'thave to worry about that. The GNU linker makes sure to stop that fromhappening when an input file in a different format has relocations.Linking input files of different object file formats together is quiteunusual, but if you're really dedicated you may want to consider testingthis case, both when the output object file format is the same as yourformat, and when it is different. BFD relocation codes BFD has another way of describing relocations besides the howto structures described above: the enum ‘bfd_reloc_code_real_type’. Every known relocation type can be described as a value in this enumeration. The enumeration contains many target specific relocations, but where two or more targets have the same relocation, a single code is used. For example, the single value ‘BFD_RELOC_32’ is used for all simple 32 bit relocation types. The main purpose of this relocation code is to give the assembler some mechanism to create ‘arelent’ structures. In order for the assembler to create an ‘arelent’ structure, it has to be able to obtain a howto structure. The function ‘bfd_reloc_type_lookup’, which simply calls the target vector entry point ‘reloc_type_lookup’, takes a relocation code and returns a howto structure. The function ‘bfd_get_reloc_code_name’ returns the name of a relocation code. This is mainly used in error messages. Using both howto structures and relocation codes can be somewhat confusing. There are many processor specific relocation codes. However, the relocation is only fully defined by the howto structure. The same relocation code will map to different howto structures in different object file formats. For example, the addend handling may be different. Most of the relocation codes are not really general. The assembler can not use them without already understanding what sorts of relocations can be used for a particular target. It might be possible to replace the relocation codes with something simpler. BFD relocation future Clearly the current BFD relocation support is in bad shape. A wholescale rewrite would be very difficult, because it would require thorough testing of every BFD target. So some sort of incremental change is required. My vague thoughts on this would involve defining a new, clearly defined, howto structure. Some mechanism would be used to determine which type of howto structure was being used by a particular format. The new howto structure would clearly define the relocation behaviour in the case of an assembly, a relocatable link, and a final link. At least one special function would be defined as an escape, and it might make sense to define more. One or more generic functions similar to ‘bfd_perform_relocation’ would be written to handle the new howto structure. This should make it possible to write a generic version of the relocate section functions used by the new linker. The target specific code would provide some mechanism (a function pointer or an initial conversion) to convert target specific relocations into howto structures. Ideally it would be possible to use this generic relocate section function for the generic linker as well. That is, it would replace the ‘bfd_generic_get_relocated_section_contents’ function which is currently normally used. For the special case of ELF dynamic linking, more consideration needs to be given to writing ELF specific but ELF target generic code to handle special relocation types such as GOT and PLT. BFD ELF support elf support in bfd bfd elf support The ELF object file format is defined in two parts: a generic ABI and a processor specific supplement. The ELF support in BFD is split in a similar fashion. The processor specific support is largely kept within a single file. The generic support is provided by several other files. The processor specific support provides a set of function pointers and constants used by the generic support. ELF sections and segments The ELF ABI permits a file to have either sections or segments or both. Relocatable object files conventionally have only sections. Executables conventionally have both. Core files conventionally have only program segments. ELF sections are similar to sections in other object file formats: they have a name, a VMA, file contents, flags, and other miscellaneous information. ELF relocations are stored in sections of a particular type; BFD automatically converts these sections into internal relocation information. ELF program segments are intended for fast interpretation by a system loader. They have a type, a VMA, an LMA, file contents, and a couple of other fields. When an ELF executable is run on a Unix system, the system loader will examine the program segments to decide how to load it. The loader will ignore the section information. Loadable program segments (type ‘PT_LOAD’) are directly loaded into memory. Other program segments are interpreted by the loader, and generally provide dynamic linking information. When an ELF file has both program segments and sections, an ELF program segment may encompass one or more ELF sections, in the sense that the portion of the file which corresponds to the program segment may include the portions of the file corresponding to one or more sections. When there is more than one section in a loadable program segment, the relative positions of the section contents in the file must correspond to the relative positions they should hold when the program segment is loaded. This requirement should be obvious if you consider that the system loader will load an entire program segment at a time. On a system which supports dynamic paging, such as any native Unix system, the contents of a loadable program segment must be at the same offset in the file as in memory, modulo the memory page size used on the system. This is because the system loader will map the file into memory starting at the start of a page. The system loader can easily remap entire pages to the correct load address. However, if the contents of the file were not correctly aligned within the page, the system loader would have to shift the contents around within the page, which is too expensive. For example, if the LMA of a loadable program segment is ‘0x40080’ and the page size is ‘0x1000’, then the position of the segment contents within the file must equal ‘0x80’ modulo ‘0x1000’. BFD has only a single set of sections. It does not provide any generic way to examine both sections and segments. When BFD is used to open an object file or executable, the BFD sections will represent ELF sections. When BFD is used to open a core file, the BFD sections will represent ELF program segments. When BFD is used to examine an object file or executable, any program segments will be read to set the LMA of the sections. This is because ELF sections only have a VMA, while ELF program segments have both a VMA and an LMA. Any program segments will be copied by the ‘copy_private’ entry points. They will be printed by the ‘print_private’ entry point. Otherwise, the program segments are ignored. In particular, programs which use BFD currently have no direct access to the program segments. When BFD is used to create an executable, the program segments will be created automatically based on the section information. This is done in the function ‘assign_file_positions_for_segments’ in elf.c. This function has been tweaked many times, and probably still has problems that arise in particular cases. There is a hook which may be used to explicitly define the program segments when creating an executable: the ‘bfd_record_phdr’ function in bfd.c. If this function is called, BFD will not create program segments itself, but will only create the program segments specified by the caller. The linker uses this function to implement the ‘PHDRS’ linker script command. BFD ELF generic support In general, functions which do not read external data from the ELF file are found in elf.c. They operate on the internal forms of the ELF structures, which are defined in include/elf/internal.h. The internal structures are defined in terms of ‘bfd_vma’, and so may be used for both 32 bit and 64 bit ELF targets. The file elfcode.h contains functions which operate on the external data. elfcode.h is compiled twice, once via elf32.c with ‘ARCH_SIZE’ defined as ‘32’, and once via elf64.c with ‘ARCH_SIZE’ defined as ‘64’. elfcode.h includes functions to swap the ELF structures in and out of external form, as well as a few more complex functions. Linker support is found in elflink.c. The linker support is only used if the processor specific file defines ‘elf_backend_relocate_section’, which is required to relocate the section contents. If that macro is not defined, the generic linker code is used, and relocations are handled via ‘bfd_perform_relocation’. The core file support is in elfcore.h, which is compiled twice, for both 32 and 64 bit support. The more interesting cases of core file support only work on a native system which has the sys/procfs.h header file. Without that file, the core file support does little more than read the ELF program segments as BFD sections. The BFD internal header file elf-bfd.h is used for communication among these files and the processor specific files. The default entries for the BFD ELF target vector are found mainly in elf.c. Some functions are found in elfcode.h. The processor specific files may override particular entries in the target vector, but most do not, with one exception: the ‘bfd_reloc_type_lookup’ entry point is always processor specific. BFD ELF processor specific support By convention, the processor specific support for a particular processor will be found in elfnn-cpu.c, where nn is either 32 or 64, and cpu is the name of the processor. Required processor specific support When writing a elfnn-cpu.c file, you must do the following: Define either ‘TARGET_BIG_SYM’ or ‘TARGET_LITTLE_SYM’, orboth, to a unique C name to use for the target vector. This name shouldappear in the list of target vectors in targets.c, and will alsohave to appear in config.bfd and configure.in. Define‘TARGET_BIG_SYM’ for a big-endian processor,‘TARGET_LITTLE_SYM’ for a little-endian processor, and define bothfor a bi-endian processor. Define either ‘TARGET_BIG_NAME’ or ‘TARGET_LITTLE_NAME’, orboth, to a string used as the name of the target vector. This is thename which a user of the BFD tool would use to specify the object fileformat. It would normally appear in a linker emulation parametersfile. Define ‘ELF_ARCH’ to the BFD architecture (an element of the‘bfd_architecture’ enum, typically ‘bfd_arch_cpu’). Define ‘ELF_MACHINE_CODE’ to the magic number which should appearin the ‘e_machine’ field of the ELF header. As of this writing,these magic numbers are assigned by Caldera; if you want to get a magicnumber for a particular processor, try sending a note to. In the BFD sources, the magic numbers arefound in include/elf/common.h; they have names beginning with‘EM_’. Define ‘ELF_MAXPAGESIZE’ to the maximum size of a virtual page inmemory. This can normally be found at the start of chapter 5 in theprocessor specific supplement. For a processor which will only be usedin an embedded system, or which has no memory management hardware, thiscan simply be ‘1’. If the format should use ‘Rel’ rather than ‘Rela’ relocations,define ‘USE_REL’. This is normally defined in chapter 4 of theprocessor specific supplement.In the absence of a supplement, it's easier to work with ‘Rela’relocations. ‘Rela’ relocations will require more space in objectfiles (but not in executables, except when using dynamic linking).However, this is outweighed by the simplicity of addend handling whenusing ‘Rela’ relocations. With ‘Rel’ relocations, the addendmust be stored in the section contents, which makes relocatable linksmore complex.For example, consider C code like i = a[1000]; where ‘a’ isa global array. The instructions which load the value of ‘a[1000]’will most likely use a relocation which refers to the symbolrepresenting ‘a’, with an addend that gives the offset from thestart of ‘a’ to element ‘1000’. When using ‘Rel’relocations, that addend must be stored in the instructions themselves.If you are adding support for a RISC chip which uses two or moreinstructions to load an address, then the addend may not fit in a singleinstruction, and will have to be somehow split among the instructions.This makes linking awkward, particularly when doing a relocatable linkin which the addend may have to be updated. It can be done—the MIPSELF support does it—but it should be avoided when possible.It is possible, though somewhat awkward, to support both ‘Rel’ and‘Rela’ relocations for a single target; elf64-mips.c does itby overriding the relocation reading and writing routines. Define howto structures for all the relocation types. Define a ‘bfd_reloc_type_lookup’ routine. This must be named‘bfd_elfnn_bfd_reloc_type_lookup’, and may be either afunction or a macro. It must translate a BFD relocation code into ahowto structure. This is normally a table lookup or a simple switch. If using ‘Rel’ relocations, define ‘elf_info_to_howto_rel’.If using ‘Rela’ relocations, define ‘elf_info_to_howto’.Either way, this is a macro defined as the name of a function whichtakes an ‘arelent’ and a ‘Rel’ or ‘Rela’ structure, andsets the ‘howto’ field of the ‘arelent’ based on the‘Rel’ or ‘Rela’ structure. This is normally uses‘ELFnn_R_TYPE’ to get the ELF relocation type and uses it asan index into a table of howto structures. You must also add the magic number for this processor to the ‘prep_headers’ function in elf.c. You must also create a header file in the include/elf directory called cpu.h. This file should define any target specific information which may be needed outside of the BFD code. In particular it should use the ‘START_RELOC_NUMBERS’, ‘RELOC_NUMBER’, ‘FAKE_RELOC’, ‘EMPTY_RELOC’ and ‘END_RELOC_NUMBERS’ macros to create a table mapping the number used to identify a relocation to a name describing that relocation. While not a BFD component, you probably also want to make the binutils program ‘readelf’ parse your ELF objects. For this, you need to add code for EM_cpu as appropriate in binutils/readelf.c. Processor specific linker support The linker will be much more efficient if you define a relocate section function. This will permit BFD to use the ELF specific linker support. If you do not define a relocate section function, BFD must use the generic linker support, which requires converting all symbols and relocations into BFD ‘asymbol’ and ‘arelent’ structures. In this case, relocations will be handled by calling ‘bfd_perform_relocation’, which will use the howto structures you have defined. See . In order to support linking into a different object file format, such as S-records, ‘bfd_perform_relocation’ must work correctly with your howto structures, so you can't skip that step. However, if you define the relocate section function, then in the normal case of linking into an ELF file the linker will not need to convert symbols and relocations, and will be much more efficient. To use a relocation section function, define the macro ‘elf_backend_relocate_section’ as the name of a function which will take the contents of a section, as well as relocation, symbol, and other information, and modify the section contents according to the relocation information. In simple cases, this is little more than a loop over the relocations which computes the value of each relocation and calls ‘_bfd_final_link_relocate’. The function must check for a relocatable link, and in that case normally needs to do nothing other than adjust the addend for relocations against a section symbol. The complex cases generally have to do with dynamic linker support. GOT and PLT relocations must be handled specially, and the linker normally arranges to set up the GOT and PLT sections while handling relocations. When generating a shared library, random relocations must normally be copied into the shared library, or converted to RELATIVE relocations when possible. Other processor specific support options There are many other macros which may be defined in elfnn-cpu.c. These macros may be found in elfxx-target.h. Macros may be used to override some of the generic ELF target vector functions. Several processor specific hook functions which may be defined as macros. These functions are found as function pointers in the ‘elf_backend_data’ structure defined in elf-bfd.h. In general, a hook function is set by defining a macro ‘elf_backend_name’. There are a few processor specific constants which may also be defined. These are again found in the ‘elf_backend_data’ structure. I will not define the various functions and constants here; see the comments in elf-bfd.h. Normally any odd characteristic of a particular ELF processor is handled via a hook function. For example, the special ‘SHN_MIPS_SCOMMON’ section number found in MIPS ELF is handled via the hooks ‘section_from_bfd_section’, ‘symbol_processing’, ‘add_symbol_hook’, and ‘output_symbol_hook’. Dynamic linking support, which involves processor specific relocations requiring special handling, is also implemented via hook functions. BFD ELF core files elf core files On native ELF Unix systems, core files are generated without any sections. Instead, they only have program segments. When BFD is used to read an ELF core file, the BFD sections will actually represent program segments. Since ELF program segments do not have names, BFD will invent names like ‘segmentn’ where n is a number. A single ELF program segment may include both an initialized part and an uninitialized part. The size of the initialized part is given by the ‘p_filesz’ field. The total size of the segment is given by the ‘p_memsz’ field. If ‘p_memsz’ is larger than ‘p_filesz’, then the extra space is uninitialized, or, more precisely, initialized to zero. BFD will represent such a program segment as two different sections. The first, named ‘segmentna’, will represent the initialized part of the program segment. The second, named ‘segmentnb’, will represent the uninitialized part. ELF core files store special information such as register values in program segments with the type ‘PT_NOTE’. BFD will attempt to interpret the information in these segments, and will create additional sections holding the information. Some of this interpretation requires information found in the host header file sys/procfs.h, and so will only work when BFD is built on a native system. BFD does not currently provide any way to create an ELF core file. In general, BFD does not provide a way to create core files. The way to implement this would be to write ‘bfd_set_format’ and ‘bfd_write_contents’ routines for the ‘bfd_core’ type; see . BFD ELF future The current dynamic linking support has too much code duplication. While each processor has particular differences, much of the dynamic linking support is quite similar for each processor. The GOT and PLT are handled in fairly similar ways, the details of -Bsymbolic linking are generally similar, etc. This code should be reworked to use more generic functions, eliminating the duplication. Similarly, the relocation handling has too much duplication. Many of the ‘reloc_type_lookup’ and ‘info_to_howto’ functions are quite similar. The relocate section functions are also often quite similar, both in the standard linker handling and the dynamic linker handling. Many of the COFF processor specific backends share a single relocate section function (‘_bfd_coff_generic_relocate_section’), and it should be possible to do something like this for the ELF targets as well. The appearance of the processor specific magic number in ‘prep_headers’ in elf.c is somewhat bogus. It should be possible to add support for a new processor without changing the generic support. The processor function hooks and constants are ad hoc and need better documentation. BFD glossary glossary for bfd bfd glossary This is a short glossary of some BFD terms. a.out The a.out object file format. The original Unix object file format.Still used on SunOS, though not Solaris. Supports only three sections. archive A collection of object files produced and manipulated by the ‘ar’program. backend The implementation within BFD of a particular object file format. Theset of functions which appear in a particular target vector. BFD The BFD library itself. Also, each object file, archive, or executableopened by the BFD library has the type ‘bfd *’, and is sometimesreferred to as a bfd. COFF The Common Object File Format. Used on Unix SVR3. Used by someembedded targets, although ELF is normally better. DLL A shared library on Windows. dynamic linker When a program linked against a shared library is run, the dynamiclinker will locate the appropriate shared library and arrange to somehowinclude it in the running image. dynamic object Another name for an ELF shared library. ECOFF The Extended Common Object File Format. Used on Alpha Digital Unix(formerly OSF/1), as well as Ultrix and Irix 4. A variant of COFF. ELF The Executable and Linking Format. The object file format used on mostmodern Unix systems, including GNU/Linux, Solaris, Irix, and SVR4. Alsoused on many embedded systems. executable A program, with instructions and symbols, and perhaps dynamic linkinginformation. Normally produced by a linker. LMA Load Memory Address. This is the address at which a section will beloaded. Compare with VMA, below. NLM NetWare Loadable Module. Used to describe the format of an object whichbe loaded into NetWare, which is some kind of PC based network serverprogram. object file A binary file including machine instructions, symbols, and relocationinformation. Normally produced by an assembler. object file format The format of an object file. Typically object files and executablesfor a particular system are in the same format, although executableswill not contain any relocation information. PE The Portable Executable format. This is the object file format used forWindows (specifically, Win32) object files. It is based closely onCOFF, but has a few significant differences. PEI The Portable Executable Image format. This is the object file formatused for Windows (specifically, Win32) executables. It is very similarto PE, but includes some additional header information. relocations Information used by the linker to adjust section contents. Also calledrelocs. section Object files and executable are composed of sections. Sections haveoptional data and optional relocation information. shared library A library of functions which may be used by many executables withoutactually being linked into each executable. There are several differentimplementations of shared libraries, each having slightly differentfeatures. symbol Each object file and executable may have a list of symbols, oftenreferred to as the symbol table. A symbol is basically a name and anaddress. There may also be some additional information like the type ofsymbol, although the type of a symbol is normally something simple likefunction or object, and should be confused with the more complex Cnotion of type. Typically every global function and variable in a Cprogram will have an associated symbol. target vector A set of functions which implement support for a particular object fileformat. The ‘bfd_target’ structure. Win32 The current Windows API, implemented by Windows 95 and later and WindowsNT 3.51 and later, but not by Windows 3.1. XCOFF The eXtended Common Object File Format. Used on AIX. A variant ofCOFF, with a completely different symbol table implementation. VMA Virtual Memory Address. This is the address a section will have whenan executable is run. Compare with LMA, above. xreflabel="Index" id="Index"> Index ‘BFD_JUMP_TABLE’, see ‘BFD_JUMP_TABLE_ARCHIVE’, see ‘BFD_JUMP_TABLE_COPY’, see ‘BFD_JUMP_TABLE_CORE’, see ‘BFD_JUMP_TABLE_DYNAMIC’, see ‘BFD_JUMP_TABLE_GENERIC’, see ‘BFD_JUMP_TABLE_LINK’, see ‘BFD_JUMP_TABLE_RELOCS’, see ‘BFD_JUMP_TABLE_SYMBOLS’, see ‘BFD_JUMP_TABLE_WRITE’, see aout-target.h, see aoutf1.h, see aoutx.h, see B bfd elf support, see bfd generated files, see bfd glossary, see bfd internals, see bfd programming guidelines, see bfd relocation handling, see bfd target vector, see bfd-in2.h, see bfd-in3.h, see bfd.h, see coffcode.h, see coffswap.h, see ecoffswap.h, see E elf core files, see elf support in bfd, see elf32-target.h, see elf64-target.h, see elfcode.h, see elfcore.h, see elfxx-target.h, see freebsd.h, see G generated files in bfd, see glossary for bfd, see guidelines, bfd programming, see libbfd.h, see libcoff.h, see netbsd.h, see nlm-target.h, see nlmcode.h, see nlmswap.h, see peicode.h, see P programming guidelines for bfd, see R relocations in bfd, see T target vector in bfd, see targmatch.h, see