START-INFO-DIR-ENTRY * Bfd: (bfd). The Binary File Descriptor library. END-INFO-DIR-ENTRY This file documents the BFD library. Copyright (C) 1991 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, subject to the terms of the GNU General Public License, which includes the provision that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions. This file documents the binary file descriptor library libbfd. Introduction ************ BFD is a package which allows applications to use the same routines to operate on object files whatever the object file format. A new object file format can be supported simply by creating a new BFD back end and adding it to the library. BFD is split into two parts: the front end, and the back ends (one for each object file format). * The front end of BFD provides the interface to the user. It manages memory and various canonical data structures. The front end also decides which back end to use and when to call back end routines. * The back ends provide BFD its view of the real world. Each back end provides a set of calls which the BFD front end can use to maintain its canonical form. The back ends also may keep around information for their own use, for greater efficiency. History ======= One spur behind BFD was the desire, on the part of the GNU 960 team at Intel Oregon, for interoperability of applications on their COFF and b.out file formats. Cygnus was providing GNU support for the team, and was contracted to provide the required functionality. The name came from a conversation David Wallace was having with Richard Stallman about the library: RMS said that it would be quite hard--David said "BFD". Stallman was right, but the name stuck. At the same time, Ready Systems wanted much the same thing, but for different object file formats: IEEE-695, Oasys, Srecords, a.out and 68k coff. BFD was first implemented by members of Cygnus Support; Steve Chamberlain (`sac@cygnus.com'), John Gilmore (`gnu@cygnus.com'), K. Richard Pixley (`rich@cygnus.com') and David Henkel-Wallace (`gumby@cygnus.com'). How To Use BFD ============== To use the library, include `bfd.h' and link with `libbfd.a'. BFD provides a common interface to the parts of an object file for a calling application. When an application sucessfully opens a target file (object, archive, or whatever), a pointer to an internal structure is returned. This pointer points to a structure called `bfd', described in `bfd.h'. Our convention is to call this pointer a BFD, and instances of it within code `abfd'. All operations on the target object file are applied as methods to the BFD. The mapping is defined within `bfd.h' in a set of macros, all beginning with `bfd_' to reduce namespace pollution. For example, this sequence does what you would probably expect: return the number of sections in an object file attached to a BFD `abfd'. #include "bfd.h" unsigned int number_of_sections(abfd) bfd *abfd; { return bfd_count_sections(abfd); } The abstraction used within BFD is that an object file has: * a header, * a number of sections containing raw data (*note Sections::.), * a set of relocations (*note Relocations::.), and * some symbol information (*note Symbols::.). Also, BFDs opened for archives have the additional attribute of an index and contain subordinate BFDs. This approach is fine for a.out and coff, but loses efficiency when applied to formats such as S-records and IEEE-695. What BFD Version 2 Can Do ========================= When an object file is opened, BFD subroutines automatically determine the format of the input object file. They then build a descriptor in memory with pointers to routines that will be used to access elements of the object file's data structures. As different information from the the object files is required, BFD reads from different sections of the file and processes them. For example, a very common operation for the linker is processing symbol tables. Each BFD back end provides a routine for converting between the object file's representation of symbols and an internal canonical format. When the linker asks for the symbol table of an object file, it calls through a memory pointer to the routine from the relevant BFD back end which reads and converts the table into a canonical form. The linker then operates upon the canonical form. When the link is finished and the linker writes the output file's symbol table, another BFD back end routine is called to take the newly created symbol table and convert it into the chosen output format. Information Loss ---------------- *Information can be lost during output.* The output formats supported by BFD do not provide identical facilities, and information which can be described in one form has nowhere to go in another format. One example of this is alignment information in `b.out'. There is nowhere in an `a.out' format file to store alignment information on the contained data, so when a file is linked from `b.out' and an `a.out' image is produced, alignment information will not propagate to the output file. (The linker will still use the alignment information internally, so the link is performed correctly). Another example is COFF section names. COFF files may contain an unlimited number of sections, each one with a textual section name. If the target of the link is a format which does not have many sections (e.g., `a.out') or has sections without names (e.g., the Oasys format), the link cannot be done simply. You can circumvent this problem by describing the desired input-to-output section mapping with the linker command language. *Information can be lost during canonicalization.* The BFD internal canonical form of the external formats is not exhaustive; there are structures in input formats for which there is no direct representation internally. This means that the BFD back ends cannot maintain all possible data richness through the transformation between external to internal and back to external formats. This limitation is only a problem when an application reads one format and writes another. Each BFD back end is responsible for maintaining as much data as possible, and the internal BFD canonical form has structures which are opaque to the BFD core, and exported only to the back ends. When a file is read in one format, the canonical form is generated for BFD and the application. At the same time, the back end saves away any information which may otherwise be lost. If the data is then written back in the same format, the back end routine will be able to use the canonical form provided by the BFD core as well as the information it prepared earlier. Since there is a great deal of commonality between back ends, there is no information lost when linking or copying big endian COFF to little endian COFF, or `a.out' to `b.out'. When a mixture of formats is linked, the information is only lost from the files whose format differs from the destination. The BFD canonical object-file format ------------------------------------ The greatest potential for loss of information occurs when there is the least overlap between the information provided by the source format, that stored by the canonical format, and that needed by the destination format. A brief description of the canonical form may help you understand which kinds of data you can count on preserving across conversions. *files* Information stored on a per-file basis includes target machine architecture, particular implementation format type, a demand pageable bit, and a write protected bit. Information like Unix magic numbers is not stored here--only the magic numbers' meaning, so a `ZMAGIC' file would have both the demand pageable bit and the write protected text bit set. The byte order of the target is stored on a per-file basis, so that big- and little-endian object files may be used with one another. *sections* Each section in the input file contains the name of the section, the section's original address in the object file, size and alignment information, various flags, and pointers into other BFD data structures. *symbols* Each symbol contains a pointer to the information for the object file which originally defined it, its name, its value, and various flag bits. When a BFD back end reads in a symbol table, it relocates all symbols to make them relative to the base of the section where they were defined. Doing this ensures that each symbol points to its containing section. Each symbol also has a varying amount of hidden private data for the BFD back end. Since the symbol points to the original file, the private data format for that symbol is accessible. `ld' can operate on a collection of symbols of wildly different formats without problems. Normal global and simple local symbols are maintained on output, so an output file (no matter its format) will retain symbols pointing to functions and to global, static, and common variables. Some symbol information is not worth retaining; in `a.out', type information is stored in the symbol table as long symbol names. This information would be useless to most COFF debuggers; the linker has command line switches to allow users to throw it away. There is one word of type information within the symbol, so if the format supports symbol type information within symbols (for example, COFF, IEEE, Oasys) and the type is simple enough to fit within one word (nearly everything but aggregates), the information will be preserved. *relocation level* Each canonical BFD relocation record contains a pointer to the symbol to relocate to, the offset of the data to relocate, the section the data is in, and a pointer to a relocation type descriptor. Relocation is performed by passing messages through the relocation type descriptor and the symbol pointer. Therefore, relocations can be performed on output data using a relocation method that is only available in one of the input formats. For instance, Oasys provides a byte relocation format. A relocation record requesting this relocation type would point indirectly to a routine to perform this, so the relocation may be performed on a byte being written to a 68k COFF file, even though 68k COFF has no such relocation type. *line numbers* Object formats can contain, for debugging purposes, some form of mapping between symbols, source line numbers, and addresses in the output file. These addresses have to be relocated along with the symbol information. Each symbol with an associated list of line number records points to the first record of the list. The head of a line number list consists of a pointer to the symbol, which allows finding out the address of the function whose line number is being described. The rest of the list is made up of pairs: offsets into the section and line numbers. Any format which can simply derive this information can pass it successfully between formats (COFF, IEEE and Oasys). BFD front end ************* `typedef bfd' ============= A BFD has type `bfd'; objects of this type are the cornerstone of any application using BFD. Using BFD consists of making references though the BFD and to data in the BFD. Here is the structure that defines the type `bfd'. It contains the major data about the file and pointers to the rest of the data. struct _bfd { /* The filename the application opened the BFD with. */ CONST char *filename; /* A pointer to the target jump table. */ const struct bfd_target *xvec; /* To avoid dragging too many header files into every file that includes ``bfd.h'', IOSTREAM has been declared as a "char *", and MTIME as a "long". Their correct types, to which they are cast when used, are "FILE *" and "time_t". The iostream is the result of an fopen on the filename. However, if the BFD_IN_MEMORY flag is set, then iostream is actually a pointer to a bfd_in_memory struct. */ PTR iostream; /* Is the file descriptor being cached? That is, can it be closed as needed, and re-opened when accessed later? */ boolean cacheable; /* Marks whether there was a default target specified when the BFD was opened. This is used to select which matching algorithm to use to choose the back end. */ boolean target_defaulted; /* The caching routines use these to maintain a least-recently-used list of BFDs */ struct _bfd *lru_prev, *lru_next; /* When a file is closed by the caching routines, BFD retains state information on the file here: */ file_ptr where; /* and here: (``once'' means at least once) */ boolean opened_once; /* Set if we have a locally maintained mtime value, rather than getting it from the file each time: */ boolean mtime_set; /* File modified time, if mtime_set is true: */ long mtime; /* Reserved for an unimplemented file locking extension.*/ int ifd; /* The format which belongs to the BFD. (object, core, etc.) */ bfd_format format; /* The direction the BFD was opened with*/ enum bfd_direction {no_direction = 0, read_direction = 1, write_direction = 2, both_direction = 3} direction; /* Format_specific flags*/ flagword flags; /* Currently my_archive is tested before adding origin to anything. I believe that this can become always an add of origin, with origin set to 0 for non archive files. */ file_ptr origin; /* Remember when output has begun, to stop strange things from happening. */ boolean output_has_begun; /* Pointer to linked list of sections*/ struct sec *sections; /* The number of sections */ unsigned int section_count; /* Stuff only useful for object files: The start address. */ bfd_vma start_address; /* Used for input and output*/ unsigned int symcount; /* Symbol table for output BFD (with symcount entries) */ struct symbol_cache_entry **outsymbols; /* Pointer to structure which contains architecture information*/ const struct bfd_arch_info *arch_info; /* Stuff only useful for archives:*/ PTR arelt_data; struct _bfd *my_archive; /* The containing archive BFD. */ struct _bfd *next; /* The next BFD in the archive. */ struct _bfd *archive_head; /* The first BFD in the archive. */ boolean has_armap; /* A chain of BFD structures involved in a link. */ struct _bfd *link_next; /* A field used by _bfd_generic_link_add_archive_symbols. This will be used only for archive elements. */ int archive_pass; /* Used by the back end to hold private data. */ union { struct aout_data_struct *aout_data; struct artdata *aout_ar_data; struct _oasys_data *oasys_obj_data; struct _oasys_ar_data *oasys_ar_data; struct coff_tdata *coff_obj_data; struct pe_tdata *pe_obj_data; struct xcoff_tdata *xcoff_obj_data; struct ecoff_tdata *ecoff_obj_data; struct ieee_data_struct *ieee_data; struct ieee_ar_data_struct *ieee_ar_data; struct srec_data_struct *srec_data; struct ihex_data_struct *ihex_data; struct tekhex_data_struct *tekhex_data; struct elf_obj_tdata *elf_obj_data; struct nlm_obj_tdata *nlm_obj_data; struct bout_data_struct *bout_data; struct sun_core_struct *sun_core_data; struct trad_core_struct *trad_core_data; struct som_data_struct *som_data; struct hpux_core_struct *hpux_core_data; struct hppabsd_core_struct *hppabsd_core_data; struct sgi_core_struct *sgi_core_data; struct lynx_core_struct *lynx_core_data; struct osf_core_struct *osf_core_data; struct cisco_core_struct *cisco_core_data; struct versados_data_struct *versados_data; struct netbsd_core_struct *netbsd_core_data; PTR any; } tdata; /* Used by the application to hold private data*/ PTR usrdata; /* Where all the allocated stuff under this BFD goes. This is a struct objalloc *, but we use PTR to avoid requiring the inclusion of objalloc.h. */ PTR memory; }; Error reporting =============== Most BFD functions return nonzero on success (check their individual documentation for precise semantics). On an error, they call `bfd_set_error' to set an error condition that callers can check by calling `bfd_get_error'. If that returns `bfd_error_system_call', then check `errno'. The easiest way to report a BFD error to the user is to use `bfd_perror'. Type `bfd_error_type' --------------------- The values returned by `bfd_get_error' are defined by the enumerated type `bfd_error_type'. typedef enum bfd_error { bfd_error_no_error = 0, bfd_error_system_call, bfd_error_invalid_target, bfd_error_wrong_format, bfd_error_invalid_operation, bfd_error_no_memory, bfd_error_no_symbols, bfd_error_no_armap, bfd_error_no_more_archived_files, bfd_error_malformed_archive, bfd_error_file_not_recognized, bfd_error_file_ambiguously_recognized, bfd_error_no_contents, bfd_error_nonrepresentable_section, bfd_error_no_debug_section, bfd_error_bad_value, bfd_error_file_truncated, bfd_error_file_too_big, bfd_error_invalid_error_code } bfd_error_type; `bfd_get_error' ............... *Synopsis* bfd_error_type bfd_get_error (void); *Description* Return the current BFD error condition. `bfd_set_error' ............... *Synopsis* void bfd_set_error (bfd_error_type error_tag); *Description* Set the BFD error condition to be ERROR_TAG. `bfd_errmsg' ............ *Synopsis* CONST char *bfd_errmsg (bfd_error_type error_tag); *Description* Return a string describing the error ERROR_TAG, or the system error if ERROR_TAG is `bfd_error_system_call'. `bfd_perror' ............ *Synopsis* void bfd_perror (CONST char *message); *Description* Print to the standard error stream a string describing the last BFD error that occurred, or the last system error if the last BFD error was a system call failure. If MESSAGE is non-NULL and non-empty, the error string printed is preceded by MESSAGE, a colon, and a space. It is followed by a newline. BFD error handler ----------------- Some BFD functions want to print messages describing the problem. They call a BFD error handler function. This function may be overriden by the program. The BFD error handler acts like printf. typedef void (*bfd_error_handler_type) PARAMS ((const char *, ...)); `bfd_set_error_handler' ....................... *Synopsis* bfd_error_handler_type bfd_set_error_handler (bfd_error_handler_type); *Description* Set the BFD error handler function. Returns the previous function. `bfd_set_error_program_name' ............................ *Synopsis* void bfd_set_error_program_name (const char *); *Description* Set the program name to use when printing a BFD error. This is printed before the error message followed by a colon and space. The string must not be changed after it is passed to this function. `bfd_get_error_handler' ....................... *Synopsis* bfd_error_handler_type bfd_get_error_handler (void); *Description* Return the BFD error handler function. Symbols ======= `bfd_get_reloc_upper_bound' ........................... *Synopsis* long bfd_get_reloc_upper_bound(bfd *abfd, asection *sect); *Description* Return the number of bytes required to store the relocation information associated with section SECT attached to bfd ABFD. If an error occurs, return -1. `bfd_canonicalize_reloc' ........................ *Synopsis* long bfd_canonicalize_reloc (bfd *abfd, asection *sec, arelent **loc, asymbol **syms); *Description* Call the back end associated with the open BFD ABFD and translate the external form of the relocation information attached to SEC into the internal canonical form. Place the table into memory at LOC, which has been preallocated, usually by a call to `bfd_get_reloc_upper_bound'. Returns the number of relocs, or -1 on error. The SYMS table is also needed for horrible internal magic reasons. `bfd_set_reloc' ............... *Synopsis* void bfd_set_reloc (bfd *abfd, asection *sec, arelent **rel, unsigned int count) *Description* Set the relocation pointer and count within section SEC to the values REL and COUNT. The argument ABFD is ignored. `bfd_set_file_flags' .................... *Synopsis* boolean bfd_set_file_flags(bfd *abfd, flagword flags); *Description* Set the flag word in the BFD ABFD to the value FLAGS. Possible errors are: * `bfd_error_wrong_format' - The target bfd was not of object format. * `bfd_error_invalid_operation' - The target bfd was open for reading. * `bfd_error_invalid_operation' - The flag word contained a bit which was not applicable to the type of file. E.g., an attempt was made to set the `D_PAGED' bit on a BFD format which does not support demand paging. `bfd_set_start_address' ....................... *Synopsis* boolean bfd_set_start_address(bfd *abfd, bfd_vma vma); *Description* Make VMA the entry point of output BFD ABFD. *Returns* Returns `true' on success, `false' otherwise. `bfd_get_mtime' ............... *Synopsis* long bfd_get_mtime(bfd *abfd); *Description* Return the file modification time (as read from the file system, or from the archive header for archive members). `bfd_get_size' .............. *Synopsis* long bfd_get_size(bfd *abfd); *Description* Return the file size (as read from file system) for the file associated with BFD ABFD. The initial motivation for, and use of, this routine is not so we can get the exact size of the object the BFD applies to, since that might not be generally possible (archive members for example). It would be ideal if someone could eventually modify it so that such results were guaranteed. Instead, we want to ask questions like "is this NNN byte sized object I'm about to try read from file offset YYY reasonable?" As as example of where we might do this, some object formats use string tables for which the first `sizeof(long)' bytes of the table contain the size of the table itself, including the size bytes. If an application tries to read what it thinks is one of these string tables, without some way to validate the size, and for some reason the size is wrong (byte swapping error, wrong location for the string table, etc.), the only clue is likely to be a read error when it tries to read the table, or a "virtual memory exhausted" error when it tries to allocate 15 bazillon bytes of space for the 15 bazillon byte table it is about to read. This function at least allows us to answer the quesion, "is the size reasonable?". `bfd_get_gp_size' ................. *Synopsis* int bfd_get_gp_size(bfd *abfd); *Description* Return the maximum size of objects to be optimized using the GP register under MIPS ECOFF. This is typically set by the `-G' argument to the compiler, assembler or linker. `bfd_set_gp_size' ................. *Synopsis* void bfd_set_gp_size(bfd *abfd, int i); *Description* Set the maximum size of objects to be optimized using the GP register under ECOFF or MIPS ELF. This is typically set by the `-G' argument to the compiler, assembler or linker. `bfd_scan_vma' .............. *Synopsis* bfd_vma bfd_scan_vma(CONST char *string, CONST char **end, int base); *Description* Convert, like `strtoul', a numerical expression STRING into a `bfd_vma' integer, and return that integer. (Though without as many bells and whistles as `strtoul'.) The expression is assumed to be unsigned (i.e., positive). If given a BASE, it is used as the base for conversion. A base of 0 causes the function to interpret the string in hex if a leading "0x" or "0X" is found, otherwise in octal if a leading zero is found, otherwise in decimal. Overflow is not detected. `bfd_copy_private_bfd_data' ........................... *Synopsis* boolean bfd_copy_private_bfd_data(bfd *ibfd, bfd *obfd); *Description* Copy private BFD information from the BFD IBFD to the the BFD OBFD. Return `true' on success, `false' on error. Possible error returns are: * `bfd_error_no_memory' - Not enough memory exists to create private data for OBFD. #define bfd_copy_private_bfd_data(ibfd, obfd) \ BFD_SEND (obfd, _bfd_copy_private_bfd_data, \ (ibfd, obfd)) `bfd_merge_private_bfd_data' ............................ *Synopsis* boolean bfd_merge_private_bfd_data(bfd *ibfd, bfd *obfd); *Description* Merge private BFD information from the BFD IBFD to the the output file BFD OBFD when linking. Return `true' on success, `false' on error. Possible error returns are: * `bfd_error_no_memory' - Not enough memory exists to create private data for OBFD. #define bfd_merge_private_bfd_data(ibfd, obfd) \ BFD_SEND (obfd, _bfd_merge_private_bfd_data, \ (ibfd, obfd)) `bfd_set_private_flags' ....................... *Synopsis* boolean bfd_set_private_flags(bfd *abfd, flagword flags); *Description* Set private BFD flag information in the BFD ABFD. Return `true' on success, `false' on error. Possible error returns are: * `bfd_error_no_memory' - Not enough memory exists to create private data for OBFD. #define bfd_set_private_flags(abfd, flags) \ BFD_SEND (abfd, _bfd_set_private_flags, \ (abfd, flags)) `stuff' ....... *Description* Stuff which should be documented: #define bfd_sizeof_headers(abfd, reloc) \ BFD_SEND (abfd, _bfd_sizeof_headers, (abfd, reloc)) #define bfd_find_nearest_line(abfd, sec, syms, off, file, func, line) \ BFD_SEND (abfd, _bfd_find_nearest_line, (abfd, sec, syms, off, file, func, line)) /* Do these three do anything useful at all, for any back end? */ #define bfd_debug_info_start(abfd) \ BFD_SEND (abfd, _bfd_debug_info_start, (abfd)) #define bfd_debug_info_end(abfd) \ BFD_SEND (abfd, _bfd_debug_info_end, (abfd)) #define bfd_debug_info_accumulate(abfd, section) \ BFD_SEND (abfd, _bfd_debug_info_accumulate, (abfd, section)) #define bfd_stat_arch_elt(abfd, stat) \ BFD_SEND (abfd, _bfd_stat_arch_elt,(abfd, stat)) #define bfd_update_armap_timestamp(abfd) \ BFD_SEND (abfd, _bfd_update_armap_timestamp, (abfd)) #define bfd_set_arch_mach(abfd, arch, mach)\ BFD_SEND ( abfd, _bfd_set_arch_mach, (abfd, arch, mach)) #define bfd_relax_section(abfd, section, link_info, again) \ BFD_SEND (abfd, _bfd_relax_section, (abfd, section, link_info, again)) #define bfd_link_hash_table_create(abfd) \ BFD_SEND (abfd, _bfd_link_hash_table_create, (abfd)) #define bfd_link_add_symbols(abfd, info) \ BFD_SEND (abfd, _bfd_link_add_symbols, (abfd, info)) #define bfd_final_link(abfd, info) \ BFD_SEND (abfd, _bfd_final_link, (abfd, info)) #define bfd_free_cached_info(abfd) \ BFD_SEND (abfd, _bfd_free_cached_info, (abfd)) #define bfd_get_dynamic_symtab_upper_bound(abfd) \ BFD_SEND (abfd, _bfd_get_dynamic_symtab_upper_bound, (abfd)) #define bfd_print_private_bfd_data(abfd, file)\ BFD_SEND (abfd, _bfd_print_private_bfd_data, (abfd, file)) #define bfd_canonicalize_dynamic_symtab(abfd, asymbols) \ BFD_SEND (abfd, _bfd_canonicalize_dynamic_symtab, (abfd, asymbols)) #define bfd_get_dynamic_reloc_upper_bound(abfd) \ BFD_SEND (abfd, _bfd_get_dynamic_reloc_upper_bound, (abfd)) #define bfd_canonicalize_dynamic_reloc(abfd, arels, asyms) \ BFD_SEND (abfd, _bfd_canonicalize_dynamic_reloc, (abfd, arels, asyms)) extern bfd_byte *bfd_get_relocated_section_contents PARAMS ((bfd *, struct bfd_link_info *, struct bfd_link_order *, bfd_byte *, boolean, asymbol **)); Memory usage ============ BFD keeps all of its internal structures in obstacks. There is one obstack per open BFD file, into which the current state is stored. When a BFD is closed, the obstack is deleted, and so everything which has been allocated by BFD for the closing file is thrown away. BFD does not free anything created by an application, but pointers into `bfd' structures become invalid on a `bfd_close'; for example, after a `bfd_close' the vector passed to `bfd_canonicalize_symtab' is still around, since it has been allocated by the application, but the data that it pointed to are lost. The general rule is to not close a BFD until all operations dependent upon data from the BFD have been completed, or all the data from within the file has been copied. To help with the management of memory, there is a function (`bfd_alloc_size') which returns the number of bytes in obstacks associated with the supplied BFD. This could be used to select the greediest open BFD, close it to reclaim the memory, perform some operation and reopen the BFD again, to get a fresh copy of the data structures. Initialization ============== These are the functions that handle initializing a BFD. `bfd_init' .......... *Synopsis* void bfd_init(void); *Description* This routine must be called before any other BFD function to initialize magical internal data structures. Sections ======== The raw data contained within a BFD is maintained through the section abstraction. A single BFD may have any number of sections. It keeps hold of them by pointing to the first; each one points to the next in the list. Sections are supported in BFD in `section.c'. Section input ------------- When a BFD is opened for reading, the section structures are created and attached to the BFD. Each section has a name which describes the section in the outside world--for example, `a.out' would contain at least three sections, called `.text', `.data' and `.bss'. Names need not be unique; for example a COFF file may have several sections named `.data'. Sometimes a BFD will contain more than the "natural" number of sections. A back end may attach other sections containing constructor data, or an application may add a section (using `bfd_make_section') to the sections attached to an already open BFD. For example, the linker creates an extra section `COMMON' for each input file's BFD to hold information about common storage. The raw data is not necessarily read in when the section descriptor is created. Some targets may leave the data in place until a `bfd_get_section_contents' call is made. Other back ends may read in all the data at once. For example, an S-record file has to be read once to determine the size of the data. An IEEE-695 file doesn't contain raw data in sections, but data and relocation expressions intermixed, so the data area has to be parsed to get out the data and relocations. Section output -------------- To write a new object style BFD, the various sections to be written have to be created. They are attached to the BFD in the same way as input sections; data is written to the sections using `bfd_set_section_contents'. Any program that creates or combines sections (e.g., the assembler and linker) must use the `asection' fields `output_section' and `output_offset' to indicate the file sections to which each section must be written. (If the section is being created from scratch, `output_section' should probably point to the section itself and `output_offset' should probably be zero.) The data to be written comes from input sections attached (via `output_section' pointers) to the output sections. The output section structure can be considered a filter for the input section: the output section determines the vma of the output data and the name, but the input section determines the offset into the output section of the data to be written. E.g., to create a section "O", starting at 0x100, 0x123 long, containing two subsections, "A" at offset 0x0 (i.e., at vma 0x100) and "B" at offset 0x20 (i.e., at vma 0x120) the `asection' structures would look like: section name "A" output_offset 0x00 size 0x20 output_section -----------> section name "O" | vma 0x100 section name "B" | size 0x123 output_offset 0x20 | size 0x103 | output_section --------| Link orders ----------- The data within a section is stored in a "link_order". These are much like the fixups in `gas'. The link_order abstraction allows a section to grow and shrink within itself. A link_order knows how big it is, and which is the next link_order and where the raw data for it is; it also points to a list of relocations which apply to it. The link_order is used by the linker to perform relaxing on final code. The compiler creates code which is as big as necessary to make it work without relaxing, and the user can select whether to relax. Sometimes relaxing takes a lot of time. The linker runs around the relocations to see if any are attached to data which can be shrunk, if so it does it on a link_order by link_order basis. typedef asection ---------------- Here is the section structure: typedef struct sec { /* The name of the section; the name isn't a copy, the pointer is the same as that passed to bfd_make_section. */ CONST char *name; /* Which section is it; 0..nth. */ int index; /* The next section in the list belonging to the BFD, or NULL. */ struct sec *next; /* The field flags contains attributes of the section. Some flags are read in from the object file, and some are synthesized from other information. */ flagword flags; #define SEC_NO_FLAGS 0x000 /* Tells the OS to allocate space for this section when loading. This is clear for a section containing debug information only. */ #define SEC_ALLOC 0x001 /* Tells the OS to load the section from the file when loading. This is clear for a .bss section. */ #define SEC_LOAD 0x002 /* The section contains data still to be relocated, so there is some relocation information too. */ #define SEC_RELOC 0x004 #if 0 /* Obsolete ? */ #define SEC_BALIGN 0x008 #endif /* A signal to the OS that the section contains read only data. */ #define SEC_READONLY 0x010 /* The section contains code only. */ #define SEC_CODE 0x020 /* The section contains data only. */ #define SEC_DATA 0x040 /* The section will reside in ROM. */ #define SEC_ROM 0x080 /* The section contains constructor information. This section type is used by the linker to create lists of constructors and destructors used by `g++'. When a back end sees a symbol which should be used in a constructor list, it creates a new section for the type of name (e.g., `__CTOR_LIST__'), attaches the symbol to it, and builds a relocation. To build the lists of constructors, all the linker has to do is catenate all the sections called `__CTOR_LIST__' and relocate the data contained within - exactly the operations it would peform on standard data. */ #define SEC_CONSTRUCTOR 0x100 /* The section is a constuctor, and should be placed at the end of the text, data, or bss section(?). */ #define SEC_CONSTRUCTOR_TEXT 0x1100 #define SEC_CONSTRUCTOR_DATA 0x2100 #define SEC_CONSTRUCTOR_BSS 0x3100 /* The section has contents - a data section could be `SEC_ALLOC' | `SEC_HAS_CONTENTS'; a debug section could be `SEC_HAS_CONTENTS' */ #define SEC_HAS_CONTENTS 0x200 /* An instruction to the linker to not output the section even if it has information which would normally be written. */ #define SEC_NEVER_LOAD 0x400 /* The section is a COFF shared library section. This flag is only for the linker. If this type of section appears in the input file, the linker must copy it to the output file without changing the vma or size. FIXME: Although this was originally intended to be general, it really is COFF specific (and the flag was renamed to indicate this). It might be cleaner to have some more general mechanism to allow the back end to control what the linker does with sections. */ #define SEC_COFF_SHARED_LIBRARY 0x800 /* The section contains common symbols (symbols may be defined multiple times, the value of a symbol is the amount of space it requires, and the largest symbol value is the one used). Most targets have exactly one of these (which we translate to bfd_com_section_ptr), but ECOFF has two. */ #define SEC_IS_COMMON 0x8000 /* The section contains only debugging information. For example, this is set for ELF .debug and .stab sections. strip tests this flag to see if a section can be discarded. */ #define SEC_DEBUGGING 0x10000 /* The contents of this section are held in memory pointed to by the contents field. This is checked by bfd_get_section_contents, and the data is retrieved from memory if appropriate. */ #define SEC_IN_MEMORY 0x20000 /* The contents of this section are to be excluded by the linker for executable and shared objects unless those objects are to be further relocated. */ #define SEC_EXCLUDE 0x40000 /* The contents of this section are to be sorted by the based on the address specified in the associated symbol table. */ #define SEC_SORT_ENTRIES 0x80000 /* When linking, duplicate sections of the same name should be discarded, rather than being combined into a single section as is usually done. This is similar to how common symbols are handled. See SEC_LINK_DUPLICATES below. */ #define SEC_LINK_ONCE 0x100000 /* If SEC_LINK_ONCE is set, this bitfield describes how the linker should handle duplicate sections. */ #define SEC_LINK_DUPLICATES 0x600000 /* This value for SEC_LINK_DUPLICATES means that duplicate sections with the same name should simply be discarded. */ #define SEC_LINK_DUPLICATES_DISCARD 0x0 /* This value for SEC_LINK_DUPLICATES means that the linker should warn if there are any duplicate sections, although it should still only link one copy. */ #define SEC_LINK_DUPLICATES_ONE_ONLY 0x200000 /* This value for SEC_LINK_DUPLICATES means that the linker should warn if any duplicate sections are a different size. */ #define SEC_LINK_DUPLICATES_SAME_SIZE 0x400000 /* This value for SEC_LINK_DUPLICATES means that the linker should warn if any duplicate sections contain different contents. */ #define SEC_LINK_DUPLICATES_SAME_CONTENTS 0x600000 /* This section was created by the linker as part of dynamic relocation or other arcane processing. It is skipped when going through the first-pass output, trusting that someone else up the line will take care of it later. */ #define SEC_LINKER_CREATED 0x800000 /* End of section flags. */ /* Some internal packed boolean fields. */ /* See the vma field. */ unsigned int user_set_vma : 1; /* Whether relocations have been processed. */ unsigned int reloc_done : 1; /* A mark flag used by some of the linker backends. */ unsigned int linker_mark : 1; /* End of internal packed boolean fields. */ /* The virtual memory address of the section - where it will be at run time. The symbols are relocated against this. The user_set_vma flag is maintained by bfd; if it's not set, the backend can assign addresses (for example, in `a.out', where the default address for `.data' is dependent on the specific target and various flags). */ bfd_vma vma; /* The load address of the section - where it would be in a rom image; really only used for writing section header information. */ bfd_vma lma; /* The size of the section in bytes, as it will be output. contains a value even if the section has no contents (e.g., the size of `.bss'). This will be filled in after relocation */ bfd_size_type _cooked_size; /* The original size on disk of the section, in bytes. Normally this value is the same as the size, but if some relaxing has been done, then this value will be bigger. */ bfd_size_type _raw_size; /* If this section is going to be output, then this value is the offset into the output section of the first byte in the input section. E.g., if this was going to start at the 100th byte in the output section, this value would be 100. */ bfd_vma output_offset; /* The output section through which to map on output. */ struct sec *output_section; /* The alignment requirement of the section, as an exponent of 2 - e.g., 3 aligns to 2^3 (or 8). */ unsigned int alignment_power; /* If an input section, a pointer to a vector of relocation records for the data in this section. */ struct reloc_cache_entry *relocation; /* If an output section, a pointer to a vector of pointers to relocation records for the data in this section. */ struct reloc_cache_entry **orelocation; /* The number of relocation records in one of the above */ unsigned reloc_count; /* Information below is back end specific - and not always used or updated. */ /* File position of section data */ file_ptr filepos; /* File position of relocation info */ file_ptr rel_filepos; /* File position of line data */ file_ptr line_filepos; /* Pointer to data for applications */ PTR userdata; /* If the SEC_IN_MEMORY flag is set, this points to the actual contents. */ unsigned char *contents; /* Attached line number information */ alent *lineno; /* Number of line number records */ unsigned int lineno_count; /* When a section is being output, this value changes as more linenumbers are written out */ file_ptr moving_line_filepos; /* What the section number is in the target world */ int target_index; PTR used_by_bfd; /* If this is a constructor section then here is a list of the relocations created to relocate items within it. */ struct relent_chain *constructor_chain; /* The BFD which owns the section. */ bfd *owner; /* A symbol which points at this section only */ struct symbol_cache_entry *symbol; struct symbol_cache_entry **symbol_ptr_ptr; struct bfd_link_order *link_order_head; struct bfd_link_order *link_order_tail; } asection ; /* These sections are global, and are managed by BFD. The application and target back end are not permitted to change the values in these sections. New code should use the section_ptr macros rather than referring directly to the const sections. The const sections may eventually vanish. */ #define BFD_ABS_SECTION_NAME "*ABS*" #define BFD_UND_SECTION_NAME "*UND*" #define BFD_COM_SECTION_NAME "*COM*" #define BFD_IND_SECTION_NAME "*IND*" /* the absolute section */ extern const asection bfd_abs_section; #define bfd_abs_section_ptr ((asection *) &bfd_abs_section) #define bfd_is_abs_section(sec) ((sec) == bfd_abs_section_ptr) /* Pointer to the undefined section */ extern const asection bfd_und_section; #define bfd_und_section_ptr ((asection *) &bfd_und_section) #define bfd_is_und_section(sec) ((sec) == bfd_und_section_ptr) /* Pointer to the common section */ extern const asection bfd_com_section; #define bfd_com_section_ptr ((asection *) &bfd_com_section) /* Pointer to the indirect section */ extern const asection bfd_ind_section; #define bfd_ind_section_ptr ((asection *) &bfd_ind_section) #define bfd_is_ind_section(sec) ((sec) == bfd_ind_section_ptr) extern const struct symbol_cache_entry * const bfd_abs_symbol; extern const struct symbol_cache_entry * const bfd_com_symbol; extern const struct symbol_cache_entry * const bfd_und_symbol; extern const struct symbol_cache_entry * const bfd_ind_symbol; #define bfd_get_section_size_before_reloc(section) \ (section->reloc_done ? (abort(),1): (section)->_raw_size) #define bfd_get_section_size_after_reloc(section) \ ((section->reloc_done) ? (section)->_cooked_size: (abort(),1)) Section prototypes ------------------ These are the functions exported by the section handling part of BFD. `bfd_get_section_by_name' ......................... *Synopsis* asection *bfd_get_section_by_name(bfd *abfd, CONST char *name); *Description* Run through ABFD and return the one of the `asection's whose name matches NAME, otherwise `NULL'. *Note Sections::, for more information. This should only be used in special cases; the normal way to process all sections of a given name is to use `bfd_map_over_sections' and `strcmp' on the name (or better yet, base it on the section flags or something else) for each section. `bfd_make_section_old_way' .......................... *Synopsis* asection *bfd_make_section_old_way(bfd *abfd, CONST char *name); *Description* Create a new empty section called NAME and attach it to the end of the chain of sections for the BFD ABFD. An attempt to create a section with a name which is already in use returns its pointer without changing the section chain. It has the funny name since this is the way it used to be before it was rewritten.... Possible errors are: * `bfd_error_invalid_operation' - If output has already started for this BFD. * `bfd_error_no_memory' - If memory allocation fails. `bfd_make_section_anyway' ......................... *Synopsis* asection *bfd_make_section_anyway(bfd *abfd, CONST char *name); *Description* Create a new empty section called NAME and attach it to the end of the chain of sections for ABFD. Create a new section even if there is already a section with that name. Return `NULL' and set `bfd_error' on error; possible errors are: * `bfd_error_invalid_operation' - If output has already started for ABFD. * `bfd_error_no_memory' - If memory allocation fails. `bfd_make_section' .................. *Synopsis* asection *bfd_make_section(bfd *, CONST char *name); *Description* Like `bfd_make_section_anyway', but return `NULL' (without calling bfd_set_error ()) without changing the section chain if there is already a section named NAME. If there is an error, return `NULL' and set `bfd_error'. `bfd_set_section_flags' ....................... *Synopsis* boolean bfd_set_section_flags(bfd *abfd, asection *sec, flagword flags); *Description* Set the attributes of the section SEC in the BFD ABFD to the value FLAGS. Return `true' on success, `false' on error. Possible error returns are: * `bfd_error_invalid_operation' - The section cannot have one or more of the attributes requested. For example, a .bss section in `a.out' may not have the `SEC_HAS_CONTENTS' field set. `bfd_map_over_sections' ....................... *Synopsis* void bfd_map_over_sections(bfd *abfd, void (*func)(bfd *abfd, asection *sect, PTR obj), PTR obj); *Description* Call the provided function FUNC for each section attached to the BFD ABFD, passing OBJ as an argument. The function will be called as if by func(abfd, the_section, obj); This is the prefered method for iterating over sections; an alternative would be to use a loop: section *p; for (p = abfd->sections; p != NULL; p = p->next) func(abfd, p, ...) `bfd_set_section_size' ...................... *Synopsis* boolean bfd_set_section_size(bfd *abfd, asection *sec, bfd_size_type val); *Description* Set SEC to the size VAL. If the operation is ok, then `true' is returned, else `false'. Possible error returns: * `bfd_error_invalid_operation' - Writing has started to the BFD, so setting the size is invalid. `bfd_set_section_contents' .......................... *Synopsis* boolean bfd_set_section_contents (bfd *abfd, asection *section, PTR data, file_ptr offset, bfd_size_type count); *Description* Sets the contents of the section SECTION in BFD ABFD to the data starting in memory at DATA. The data is written to the output section starting at offset OFFSET for COUNT bytes. Normally `true' is returned, else `false'. Possible error returns are: * `bfd_error_no_contents' - The output section does not have the `SEC_HAS_CONTENTS' attribute, so nothing can be written to it. * and some more too This routine is front end to the back end function `_bfd_set_section_contents'. `bfd_get_section_contents' .......................... *Synopsis* boolean bfd_get_section_contents (bfd *abfd, asection *section, PTR location, file_ptr offset, bfd_size_type count); *Description* Read data from SECTION in BFD ABFD into memory starting at LOCATION. The data is read at an offset of OFFSET from the start of the input section, and is read for COUNT bytes. If the contents of a constructor with the `SEC_CONSTRUCTOR' flag set are requested or if the section does not have the `SEC_HAS_CONTENTS' flag set, then the LOCATION is filled with zeroes. If no errors occur, `true' is returned, else `false'. `bfd_copy_private_section_data' ............................... *Synopsis* boolean bfd_copy_private_section_data(bfd *ibfd, asection *isec, bfd *obfd, asection *osec); *Description* Copy private section information from ISEC in the BFD IBFD to the section OSEC in the BFD OBFD. Return `true' on success, `false' on error. Possible error returns are: * `bfd_error_no_memory' - Not enough memory exists to create private data for OSEC. #define bfd_copy_private_section_data(ibfd, isection, obfd, osection) \ BFD_SEND (obfd, _bfd_copy_private_section_data, \ (ibfd, isection, obfd, osection)) Symbols ======= BFD tries to maintain as much symbol information as it can when it moves information from file to file. BFD passes information to applications though the `asymbol' structure. When the application requests the symbol table, BFD reads the table in the native form and translates parts of it into the internal format. To maintain more than the information passed to applications, some targets keep some information "behind the scenes" in a structure only the particular back end knows about. For example, the coff back end keeps the original symbol table structure as well as the canonical structure when a BFD is read in. On output, the coff back end can reconstruct the output symbol table so that no information is lost, even information unique to coff which BFD doesn't know or understand. If a coff symbol table were read, but were written through an a.out back end, all the coff specific information would be lost. The symbol table of a BFD is not necessarily read in until a canonicalize request is made. Then the BFD back end fills in a table provided by the application with pointers to the canonical information. To output symbols, the application provides BFD with a table of pointers to pointers to `asymbol's. This allows applications like the linker to output a symbol as it was read, since the "behind the scenes" information will be still available. Reading symbols --------------- There are two stages to reading a symbol table from a BFD: allocating storage, and the actual reading process. This is an excerpt from an application which reads the symbol table: long storage_needed; asymbol **symbol_table; long number_of_symbols; long i; storage_needed = bfd_get_symtab_upper_bound (abfd); if (storage_needed < 0) FAIL if (storage_needed == 0) { return ; } symbol_table = (asymbol **) xmalloc (storage_needed); ... number_of_symbols = bfd_canonicalize_symtab (abfd, symbol_table); if (number_of_symbols < 0) FAIL for (i = 0; i < number_of_symbols; i++) { process_symbol (symbol_table[i]); } All storage for the symbols themselves is in an objalloc connected to the BFD; it is freed when the BFD is closed. Writing symbols --------------- Writing of a symbol table is automatic when a BFD open for writing is closed. The application attaches a vector of pointers to pointers to symbols to the BFD being written, and fills in the symbol count. The close and cleanup code reads through the table provided and performs all the necessary operations. The BFD output code must always be provided with an "owned" symbol: one which has come from another BFD, or one which has been created using `bfd_make_empty_symbol'. Here is an example showing the creation of a symbol table with only one element: #include "bfd.h" main() { bfd *abfd; asymbol *ptrs[2]; asymbol *new; abfd = bfd_openw("foo","a.out-sunos-big"); bfd_set_format(abfd, bfd_object); new = bfd_make_empty_symbol(abfd); new->name = "dummy_symbol"; new->section = bfd_make_section_old_way(abfd, ".text"); new->flags = BSF_GLOBAL; new->value = 0x12345; ptrs[0] = new; ptrs[1] = (asymbol *)0; bfd_set_symtab(abfd, ptrs, 1); bfd_close(abfd); } ./makesym nm foo 00012345 A dummy_symbol Many formats cannot represent arbitary symbol information; for instance, the `a.out' object format does not allow an arbitary number of sections. A symbol pointing to a section which is not one of `.text', `.data' or `.bss' cannot be described. Mini Symbols ------------ Mini symbols provide read-only access to the symbol table. They use less memory space, but require more time to access. They can be useful for tools like nm or objdump, which may have to handle symbol tables of extremely large executables. The `bfd_read_minisymbols' function will read the symbols into memory in an internal form. It will return a `void *' pointer to a block of memory, a symbol count, and the size of each symbol. The pointer is allocated using `malloc', and should be freed by the caller when it is no longer needed. The function `bfd_minisymbol_to_symbol' will take a pointer to a minisymbol, and a pointer to a structure returned by `bfd_make_empty_symbol', and return a `asymbol' structure. The return value may or may not be the same as the value from `bfd_make_empty_symbol' which was passed in. typedef asymbol --------------- An `asymbol' has the form: typedef struct symbol_cache_entry { /* A pointer to the BFD which owns the symbol. This information is necessary so that a back end can work out what additional information (invisible to the application writer) is carried with the symbol. This field is *almost* redundant, since you can use section->owner instead, except that some symbols point to the global sections bfd_{abs,com,und}_section. This could be fixed by making these globals be per-bfd (or per-target-flavor). FIXME. */ struct _bfd *the_bfd; /* Use bfd_asymbol_bfd(sym) to access this field. */ /* The text of the symbol. The name is left alone, and not copied; the application may not alter it. */ CONST char *name; /* The value of the symbol. This really should be a union of a numeric value with a pointer, since some flags indicate that a pointer to another symbol is stored here. */ symvalue value; /* Attributes of a symbol: */ #define BSF_NO_FLAGS 0x00 /* The symbol has local scope; `static' in `C'. The value is the offset into the section of the data. */ #define BSF_LOCAL 0x01 /* The symbol has global scope; initialized data in `C'. The value is the offset into the section of the data. */ #define BSF_GLOBAL 0x02 /* The symbol has global scope and is exported. The value is the offset into the section of the data. */ #define BSF_EXPORT BSF_GLOBAL /* no real difference */ /* A normal C symbol would be one of: `BSF_LOCAL', `BSF_FORT_COMM', `BSF_UNDEFINED' or `BSF_GLOBAL' */ /* The symbol is a debugging record. The value has an arbitary meaning. */ #define BSF_DEBUGGING 0x08 /* The symbol denotes a function entry point. Used in ELF, perhaps others someday. */ #define BSF_FUNCTION 0x10 /* Used by the linker. */ #define BSF_KEEP 0x20 #define BSF_KEEP_G 0x40 /* A weak global symbol, overridable without warnings by a regular global symbol of the same name. */ #define BSF_WEAK 0x80 /* This symbol was created to point to a section, e.g. ELF's STT_SECTION symbols. */ #define BSF_SECTION_SYM 0x100 /* The symbol used to be a common symbol, but now it is allocated. */ #define BSF_OLD_COMMON 0x200 /* The default value for common data. */ #define BFD_FORT_COMM_DEFAULT_VALUE 0 /* In some files the type of a symbol sometimes alters its location in an output file - ie in coff a `ISFCN' symbol which is also `C_EXT' symbol appears where it was declared and not at the end of a section. This bit is set by the target BFD part to convey this information. */ #define BSF_NOT_AT_END 0x400 /* Signal that the symbol is the label of constructor section. */ #define BSF_CONSTRUCTOR 0x800 /* Signal that the symbol is a warning symbol. The name is a warning. The name of the next symbol is the one to warn about; if a reference is made to a symbol with the same name as the next symbol, a warning is issued by the linker. */ #define BSF_WARNING 0x1000 /* Signal that the symbol is indirect. This symbol is an indirect pointer to the symbol with the same name as the next symbol. */ #define BSF_INDIRECT 0x2000 /* BSF_FILE marks symbols that contain a file name. This is used for ELF STT_FILE symbols. */ #define BSF_FILE 0x4000 /* Symbol is from dynamic linking information. */ #define BSF_DYNAMIC 0x8000 /* The symbol denotes a data object. Used in ELF, and perhaps others someday. */ #define BSF_OBJECT 0x10000 flagword flags; /* A pointer to the section to which this symbol is relative. This will always be non NULL, there are special sections for undefined and absolute symbols. */ struct sec *section; /* Back end special data. */ union { PTR p; bfd_vma i; } udata; } asymbol; Symbol handling functions ------------------------- `bfd_get_symtab_upper_bound' ............................ *Description* Return the number of bytes required to store a vector of pointers to `asymbols' for all the symbols in the BFD ABFD, including a terminal NULL pointer. If there are no symbols in the BFD, then return 0. If an error occurs, return -1. #define bfd_get_symtab_upper_bound(abfd) \ BFD_SEND (abfd, _bfd_get_symtab_upper_bound, (abfd)) `bfd_is_local_label' .................... *Synopsis* boolean bfd_is_local_label(bfd *abfd, asymbol *sym); *Description* Return true if the given symbol SYM in the BFD ABFD is a compiler generated local label, else return false. `bfd_is_local_label_name' ......................... *Synopsis* boolean bfd_is_local_label_name(bfd *abfd, const char *name); *Description* Return true if a symbol with the name NAME in the BFD ABFD is a compiler generated local label, else return false. This just checks whether the name has the form of a local label. #define bfd_is_local_label_name(abfd, name) \ BFD_SEND (abfd, _bfd_is_local_label_name, (abfd, name)) `bfd_canonicalize_symtab' ......................... *Description* Read the symbols from the BFD ABFD, and fills in the vector LOCATION with pointers to the symbols and a trailing NULL. Return the actual number of symbol pointers, not including the NULL. #define bfd_canonicalize_symtab(abfd, location) \ BFD_SEND (abfd, _bfd_canonicalize_symtab,\ (abfd, location)) `bfd_set_symtab' ................ *Synopsis* boolean bfd_set_symtab (bfd *abfd, asymbol **location, unsigned int count); *Description* Arrange that when the output BFD ABFD is closed, the table LOCATION of COUNT pointers to symbols will be written. `bfd_print_symbol_vandf' ........................ *Synopsis* void bfd_print_symbol_vandf(PTR file, asymbol *symbol); *Description* Print the value and flags of the SYMBOL supplied to the stream FILE. `bfd_make_empty_symbol' ....................... *Description* Create a new `asymbol' structure for the BFD ABFD and return a pointer to it. This routine is necessary because each back end has private information surrounding the `asymbol'. Building your own `asymbol' and pointing to it will not create the private information, and will cause problems later on. #define bfd_make_empty_symbol(abfd) \ BFD_SEND (abfd, _bfd_make_empty_symbol, (abfd)) `bfd_make_debug_symbol' ....................... *Description* Create a new `asymbol' structure for the BFD ABFD, to be used as a debugging symbol. Further details of its use have yet to be worked out. #define bfd_make_debug_symbol(abfd,ptr,size) \ BFD_SEND (abfd, _bfd_make_debug_symbol, (abfd, ptr, size)) `bfd_decode_symclass' ..................... *Description* Return a character corresponding to the symbol class of SYMBOL, or '?' for an unknown class. *Synopsis* int bfd_decode_symclass(asymbol *symbol); `bfd_symbol_info' ................. *Description* Fill in the basic info about symbol that nm needs. Additional info may be added by the back-ends after calling this function. *Synopsis* void bfd_symbol_info(asymbol *symbol, symbol_info *ret); `bfd_copy_private_symbol_data' .............................. *Synopsis* boolean bfd_copy_private_symbol_data(bfd *ibfd, asymbol *isym, bfd *obfd, asymbol *osym); *Description* Copy private symbol information from ISYM in the BFD IBFD to the symbol OSYM in the BFD OBFD. Return `true' on success, `false' on error. Possible error returns are: * `bfd_error_no_memory' - Not enough memory exists to create private data for OSEC. #define bfd_copy_private_symbol_data(ibfd, isymbol, obfd, osymbol) \ BFD_SEND (obfd, _bfd_copy_private_symbol_data, \ (ibfd, isymbol, obfd, osymbol)) Archives ======== *Description* An archive (or library) is just another BFD. It has a symbol table, although there's not much a user program will do with it. The big difference between an archive BFD and an ordinary BFD is that the archive doesn't have sections. Instead it has a chain of BFDs that are considered its contents. These BFDs can be manipulated like any other. The BFDs contained in an archive opened for reading will all be opened for reading. You may put either input or output BFDs into an archive opened for output; they will be handled correctly when the archive is closed. Use `bfd_openr_next_archived_file' to step through the contents of an archive opened for input. You don't have to read the entire archive if you don't want to! Read it until you find what you want. Archive contents of output BFDs are chained through the `next' pointer in a BFD. The first one is findable through the `archive_head' slot of the archive. Set it with `bfd_set_archive_head' (q.v.). A given BFD may be in only one open output archive at a time. As expected, the BFD archive code is more general than the archive code of any given environment. BFD archives may contain files of different formats (e.g., a.out and coff) and even different architectures. You may even place archives recursively into archives! This can cause unexpected confusion, since some archive formats are more expressive than others. For instance, Intel COFF archives can preserve long filenames; SunOS a.out archives cannot. If you move a file from the first to the second format and back again, the filename may be truncated. Likewise, different a.out environments have different conventions as to how they truncate filenames, whether they preserve directory names in filenames, etc. When interoperating with native tools, be sure your files are homogeneous. Beware: most of these formats do not react well to the presence of spaces in filenames. We do the best we can, but can't always handle this case due to restrictions in the format of archives. Many Unix utilities are braindead in regards to spaces and such in filenames anyway, so this shouldn't be much of a restriction. Archives are supported in BFD in `archive.c'. `bfd_get_next_mapent' ..................... *Synopsis* symindex bfd_get_next_mapent(bfd *abfd, symindex previous, carsym **sym); *Description* Step through archive ABFD's symbol table (if it has one). Successively update SYM with the next symbol's information, returning that symbol's (internal) index into the symbol table. Supply `BFD_NO_MORE_SYMBOLS' as the PREVIOUS entry to get the first one; returns `BFD_NO_MORE_SYMBOLS' when you've already got the last one. A `carsym' is a canonical archive symbol. The only user-visible element is its name, a null-terminated string. `bfd_set_archive_head' ...................... *Synopsis* boolean bfd_set_archive_head(bfd *output, bfd *new_head); *Description* Set the head of the chain of BFDs contained in the archive OUTPUT to NEW_HEAD. `bfd_openr_next_archived_file' .............................. *Synopsis* bfd *bfd_openr_next_archived_file(bfd *archive, bfd *previous); *Description* Provided a BFD, ARCHIVE, containing an archive and NULL, open an input BFD on the first contained element and returns that. Subsequent calls should pass the archive and the previous return value to return a created BFD to the next contained element. NULL is returned when there are no more. File formats ============ A format is a BFD concept of high level file contents type. The formats supported by BFD are: * `bfd_object' The BFD may contain data, symbols, relocations and debug info. * `bfd_archive' The BFD contains other BFDs and an optional index. * `bfd_core' The BFD contains the result of an executable core dump. `bfd_check_format' .................. *Synopsis* boolean bfd_check_format(bfd *abfd, bfd_format format); *Description* Verify if the file attached to the BFD ABFD is compatible with the format FORMAT (i.e., one of `bfd_object', `bfd_archive' or `bfd_core'). If the BFD has been set to a specific target before the call, only the named target and format combination is checked. If the target has not been set, or has been set to `default', then all the known target backends is interrogated to determine a match. If the default target matches, it is used. If not, exactly one target must recognize the file, or an error results. The function returns `true' on success, otherwise `false' with one of the following error codes: * `bfd_error_invalid_operation' - if `format' is not one of `bfd_object', `bfd_archive' or `bfd_core'. * `bfd_error_system_call' - if an error occured during a read - even some file mismatches can cause bfd_error_system_calls. * `file_not_recognised' - none of the backends recognised the file format. * `bfd_error_file_ambiguously_recognized' - more than one backend recognised the file format. `bfd_check_format_matches' .......................... *Synopsis* boolean bfd_check_format_matches(bfd *abfd, bfd_format format, char ***matching); *Description* Like `bfd_check_format', except when it returns false with `bfd_errno' set to `bfd_error_file_ambiguously_recognized'. In that case, if MATCHING is not NULL, it will be filled in with a NULL-terminated list of the names of the formats that matched, allocated with `malloc'. Then the user may choose a format and try again. When done with the list that MATCHING points to, the caller should free it. `bfd_set_format' ................ *Synopsis* boolean bfd_set_format(bfd *abfd, bfd_format format); *Description* This function sets the file format of the BFD ABFD to the format FORMAT. If the target set in the BFD does not support the format requested, the format is invalid, or the BFD is not open for writing, then an error occurs. `bfd_format_string' ................... *Synopsis* CONST char *bfd_format_string(bfd_format format); *Description* Return a pointer to a const string `invalid', `object', `archive', `core', or `unknown', depending upon the value of FORMAT. Relocations =========== BFD maintains relocations in much the same way it maintains symbols: they are left alone until required, then read in en-mass and translated into an internal form. A common routine `bfd_perform_relocation' acts upon the canonical form to do the fixup. Relocations are maintained on a per section basis, while symbols are maintained on a per BFD basis. All that a back end has to do to fit the BFD interface is to create a `struct reloc_cache_entry' for each relocation in a particular section, and fill in the right bits of the structures. typedef arelent --------------- This is the structure of a relocation entry: typedef enum bfd_reloc_status { /* No errors detected */ bfd_reloc_ok, /* The relocation was performed, but there was an overflow. */ bfd_reloc_overflow, /* The address to relocate was not within the section supplied. */ bfd_reloc_outofrange, /* Used by special functions */ bfd_reloc_continue, /* Unsupported relocation size requested. */ bfd_reloc_notsupported, /* Unused */ bfd_reloc_other, /* The symbol to relocate against was undefined. */ bfd_reloc_undefined, /* The relocation was performed, but may not be ok - presently generated only when linking i960 coff files with i960 b.out symbols. If this type is returned, the error_message argument to bfd_perform_relocation will be set. */ bfd_reloc_dangerous } bfd_reloc_status_type; typedef struct reloc_cache_entry { /* A pointer into the canonical table of pointers */ struct symbol_cache_entry **sym_ptr_ptr; /* offset in section */ bfd_size_type address; /* addend for relocation value */ bfd_vma addend; /* Pointer to how to perform the required relocation */ reloc_howto_type *howto; } arelent; *Description* Here is a description of each of the fields within an `arelent': * `sym_ptr_ptr' The symbol table pointer points to a pointer to the symbol associated with the relocation request. It is the pointer into the table returned by the back end's `get_symtab' action. *Note Symbols::. The symbol is referenced through a pointer to a pointer so that tools like the linker can fix up all the symbols of the same name by modifying only one pointer. The relocation routine looks in the symbol and uses the base of the section the symbol is attached to and the value of the symbol as the initial relocation offset. If the symbol pointer is zero, then the section provided is looked up. * `address' The `address' field gives the offset in bytes from the base of the section data which owns the relocation record to the first byte of relocatable information. The actual data relocated will be relative to this point; for example, a relocation type which modifies the bottom two bytes of a four byte word would not touch the first byte pointed to in a big endian world. * `addend' The `addend' is a value provided by the back end to be added (!) to the relocation offset. Its interpretation is dependent upon the howto. For example, on the 68k the code: char foo[]; main() { return foo[0x12345678]; } Could be compiled into: linkw fp,#-4 moveb @#12345678,d0 extbl d0 unlk fp rts This could create a reloc pointing to `foo', but leave the offset in the data, something like: RELOCATION RECORDS FOR [.text]: offset type value 00000006 32 _foo 00000000 4e56 fffc ; linkw fp,#-4 00000004 1039 1234 5678 ; moveb @#12345678,d0 0000000a 49c0 ; extbl d0 0000000c 4e5e ; unlk fp 0000000e 4e75 ; rts Using coff and an 88k, some instructions don't have enough space in them to represent the full address range, and pointers have to be loaded in two parts. So you'd get something like: or.u r13,r0,hi16(_foo+0x12345678) ld.b r2,r13,lo16(_foo+0x12345678) jmp r1 This should create two relocs, both pointing to `_foo', and with 0x12340000 in their addend field. The data would consist of: RELOCATION RECORDS FOR [.text]: offset type value 00000002 HVRT16 _foo+0x12340000 00000006 LVRT16 _foo+0x12340000 00000000 5da05678 ; or.u r13,r0,0x5678 00000004 1c4d5678 ; ld.b r2,r13,0x5678 00000008 f400c001 ; jmp r1 The relocation routine digs out the value from the data, adds it to the addend to get the original offset, and then adds the value of `_foo'. Note that all 32 bits have to be kept around somewhere, to cope with carry from bit 15 to bit 16. One further example is the sparc and the a.out format. The sparc has a similar problem to the 88k, in that some instructions don't have room for an entire offset, but on the sparc the parts are created in odd sized lumps. The designers of the a.out format chose to not use the data within the section for storing part of the offset; all the offset is kept within the reloc. Anything in the data should be ignored. save %sp,-112,%sp sethi %hi(_foo+0x12345678),%g2 ldsb [%g2+%lo(_foo+0x12345678)],%i0 ret restore Both relocs contain a pointer to `foo', and the offsets contain junk. RELOCATION RECORDS FOR [.text]: offset type value 00000004 HI22 _foo+0x12345678 00000008 LO10 _foo+0x12345678 00000000 9de3bf90 ; save %sp,-112,%sp 00000004 05000000 ; sethi %hi(_foo+0),%g2 00000008 f048a000 ; ldsb [%g2+%lo(_foo+0)],%i0 0000000c 81c7e008 ; ret 00000010 81e80000 ; restore * `howto' The `howto' field can be imagined as a relocation instruction. It is a pointer to a structure which contains information on what to do with all of the other information in the reloc record and data section. A back end would normally have a relocation instruction set and turn relocations into pointers to the correct structure on input - but it would be possible to create each howto field on demand. `enum complain_overflow' ........................ Indicates what sort of overflow checking should be done when performing a relocation. enum complain_overflow { /* Do not complain on overflow. */ complain_overflow_dont, /* Complain if the bitfield overflows, whether it is considered as signed or unsigned. */ complain_overflow_bitfield, /* Complain if the value overflows when considered as signed number. */ complain_overflow_signed, /* Complain if the value overflows when considered as an unsigned number. */ complain_overflow_unsigned }; `reloc_howto_type' .................. The `reloc_howto_type' is a structure which contains all the information that libbfd needs to know to tie up a back end's data. struct symbol_cache_entry; /* Forward declaration */ struct reloc_howto_struct { /* The type field has mainly a documentary use - the back end can do what it wants with it, though normally the back end's external idea of what a reloc number is stored in this field. For example, a PC relative word relocation in a coff environment has the type 023 - because that's what the outside world calls a R_PCRWORD reloc. */ unsigned int type; /* The value the final relocation is shifted right by. This drops unwanted data from the relocation. */ unsigned int rightshift; /* The size of the item to be relocated. This is *not* a power-of-two measure. To get the number of bytes operated on by a type of relocation, use bfd_get_reloc_size. */ int size; /* The number of bits in the item to be relocated. This is used when doing overflow checking. */ unsigned int bitsize; /* Notes that the relocation is relative to the location in the data section of the addend. The relocation function will subtract from the relocation value the address of the location being relocated. */ boolean pc_relative; /* The bit position of the reloc value in the destination. The relocated value is left shifted by this amount. */ unsigned int bitpos; /* What type of overflow error should be checked for when relocating. */ enum complain_overflow complain_on_overflow; /* If this field is non null, then the supplied function is called rather than the normal function. This allows really strange relocation methods to be accomodated (e.g., i960 callj instructions). */ bfd_reloc_status_type (*special_function) PARAMS ((bfd *abfd, arelent *reloc_entry, struct symbol_cache_entry *symbol, PTR data, asection *input_section, bfd *output_bfd, char **error_message)); /* The textual name of the relocation type. */ char *name; /* When performing a partial link, some formats must modify the relocations rather than the data - this flag signals this.*/ boolean partial_inplace; /* The src_mask selects which parts of the read in data are to be used in the relocation sum. E.g., if this was an 8 bit bit of data which we read and relocated, this would be 0x000000ff. When we have relocs which have an addend, such as sun4 extended relocs, the value in the offset part of a relocating field is garbage so we never use it. In this case the mask would be 0x00000000. */ bfd_vma src_mask; /* The dst_mask selects which parts of the instruction are replaced into the instruction. In most cases src_mask == dst_mask, except in the above special case, where dst_mask would be 0x000000ff, and src_mask would be 0x00000000. */ bfd_vma dst_mask; /* When some formats create PC relative instructions, they leave the value of the pc of the place being relocated in the offset slot of the instruction, so that a PC relative relocation can be made just by adding in an ordinary offset (e.g., sun3 a.out). Some formats leave the displacement part of an instruction empty (e.g., m88k bcs); this flag signals the fact.*/ boolean pcrel_offset; }; `The HOWTO Macro' ................. *Description* The HOWTO define is horrible and will go away. #define HOWTO(C, R,S,B, P, BI, O, SF, NAME, INPLACE, MASKSRC, MASKDST, PC) \ {(unsigned)C,R,S,B, P, BI, O,SF,NAME,INPLACE,MASKSRC,MASKDST,PC} *Description* And will be replaced with the totally magic way. But for the moment, we are compatible, so do it this way. #define NEWHOWTO( FUNCTION, NAME,SIZE,REL,IN) HOWTO(0,0,SIZE,0,REL,0,complain_overflow_dont,FUNCTION, NAME,false,0,0,IN) *Description* Helper routine to turn a symbol into a relocation value. #define HOWTO_PREPARE(relocation, symbol) \ { \ if (symbol != (asymbol *)NULL) { \ if (bfd_is_com_section (symbol->section)) { \ relocation = 0; \ } \ else { \ relocation = symbol->value; \ } \ } \ } `bfd_get_reloc_size' .................... *Synopsis* unsigned int bfd_get_reloc_size (reloc_howto_type *); *Description* For a reloc_howto_type that operates on a fixed number of bytes, this returns the number of bytes operated on. `arelent_chain' ............... *Description* How relocs are tied together in an `asection': typedef struct relent_chain { arelent relent; struct relent_chain *next; } arelent_chain; `bfd_check_overflow' .................... *Synopsis* bfd_reloc_status_type bfd_check_overflow (enum complain_overflow how, unsigned int bitsize, unsigned int rightshift, bfd_vma relocation); *Description* Perform overflow checking on RELOCATION which has BITSIZE significant bits and will be shifted right by RIGHTSHIFT bits. The result is either of `bfd_reloc_ok' or `bfd_reloc_overflow'. `bfd_perform_relocation' ........................ *Synopsis* bfd_reloc_status_type bfd_perform_relocation (bfd *abfd, arelent *reloc_entry, PTR data, asection *input_section, bfd *output_bfd, char **error_message); *Description* If OUTPUT_BFD is supplied to this function, the generated image will be relocatable; the relocations are copied to the output file after they have been changed to reflect the new state of the world. There are two ways of reflecting the results of partial linkage in an output file: by modifying the output data in place, and by modifying the relocation record. Some native formats (e.g., basic a.out and basic coff) have no way of specifying an addend in the relocation type, so the addend has to go in the output data. This is no big deal since in these formats the output data slot will always be big enough for the addend. Complex reloc types with addends were invented to solve just this problem. The ERROR_MESSAGE argument is set to an error message if this return `bfd_reloc_dangerous'. `bfd_install_relocation' ........................ *Synopsis* bfd_reloc_status_type bfd_install_relocation (bfd *abfd, arelent *reloc_entry, PTR data, bfd_vma data_start, asection *input_section, char **error_message); *Description* This looks remarkably like `bfd_perform_relocation', except it does not expect that the section contents have been filled in. I.e., it's suitable for use when creating, rather than applying a relocation. For now, this function should be considered reserved for the assembler. The howto manager ================= When an application wants to create a relocation, but doesn't know what the target machine might call it, it can find out by using this bit of code. `bfd_reloc_code_type' ..................... *Description* The insides of a reloc code. The idea is that, eventually, there will be one enumerator for every type of relocation we ever do. Pass one of these values to `bfd_reloc_type_lookup', and it'll return a howto pointer. This does mean that the application must determine the correct enumerator value; you can't get a howto pointer from a random set of attributes. Here are the possible values for `enum bfd_reloc_code_real': - : BFD_RELOC_64 - : BFD_RELOC_32 - : BFD_RELOC_26 - : BFD_RELOC_24 - : BFD_RELOC_16 - : BFD_RELOC_14 - : BFD_RELOC_8 Basic absolute relocations of N bits. - : BFD_RELOC_64_PCREL - : BFD_RELOC_32_PCREL - : BFD_RELOC_24_PCREL - : BFD_RELOC_16_PCREL - : BFD_RELOC_12_PCREL - : BFD_RELOC_8_PCREL PC-relative relocations. Sometimes these are relative to the address of the relocation itself; sometimes they are relative to the start of the section containing the relocation. It depends on the specific target. The 24-bit relocation is used in some Intel 960 configurations. - : BFD_RELOC_32_GOT_PCREL - : BFD_RELOC_16_GOT_PCREL - : BFD_RELOC_8_GOT_PCREL - : BFD_RELOC_32_GOTOFF - : BFD_RELOC_16_GOTOFF - : BFD_RELOC_LO16_GOTOFF - : BFD_RELOC_HI16_GOTOFF - : BFD_RELOC_HI16_S_GOTOFF - : BFD_RELOC_8_GOTOFF - : BFD_RELOC_32_PLT_PCREL - : BFD_RELOC_24_PLT_PCREL - : BFD_RELOC_16_PLT_PCREL - : BFD_RELOC_8_PLT_PCREL - : BFD_RELOC_32_PLTOFF - : BFD_RELOC_16_PLTOFF - : BFD_RELOC_LO16_PLTOFF - : BFD_RELOC_HI16_PLTOFF - : BFD_RELOC_HI16_S_PLTOFF - : BFD_RELOC_8_PLTOFF For ELF. - : BFD_RELOC_68K_GLOB_DAT - : BFD_RELOC_68K_JMP_SLOT - : BFD_RELOC_68K_RELATIVE Relocations used by 68K ELF. - : BFD_RELOC_32_BASEREL - : BFD_RELOC_16_BASEREL - : BFD_RELOC_LO16_BASEREL - : BFD_RELOC_HI16_BASEREL - : BFD_RELOC_HI16_S_BASEREL - : BFD_RELOC_8_BASEREL - : BFD_RELOC_RVA Linkage-table relative. - : BFD_RELOC_8_FFnn Absolute 8-bit relocation, but used to form an address like 0xFFnn. - : BFD_RELOC_32_PCREL_S2 - : BFD_RELOC_16_PCREL_S2 - : BFD_RELOC_23_PCREL_S2 These PC-relative relocations are stored as word displacements - i.e., byte displacements shifted right two bits. The 30-bit word displacement (<<32_PCREL_S2>> - 32 bits, shifted 2) is used on the SPARC. (SPARC tools generally refer to this as <>.) The signed 16-bit displacement is used on the MIPS, and the 23-bit displacement is used on the Alpha. - : BFD_RELOC_HI22 - : BFD_RELOC_LO10 High 22 bits and low 10 bits of 32-bit value, placed into lower bits of the target word. These are used on the SPARC. - : BFD_RELOC_GPREL16 - : BFD_RELOC_GPREL32 For systems that allocate a Global Pointer register, these are displacements off that register. These relocation types are handled specially, because the value the register will have is decided relatively late. - : BFD_RELOC_I960_CALLJ Reloc types used for i960/b.out. - : BFD_RELOC_NONE - : BFD_RELOC_SPARC_WDISP22 - : BFD_RELOC_SPARC22 - : BFD_RELOC_SPARC13 - : BFD_RELOC_SPARC_GOT10 - : BFD_RELOC_SPARC_GOT13 - : BFD_RELOC_SPARC_GOT22 - : BFD_RELOC_SPARC_PC10 - : BFD_RELOC_SPARC_PC22 - : BFD_RELOC_SPARC_WPLT30 - : BFD_RELOC_SPARC_COPY - : BFD_RELOC_SPARC_GLOB_DAT - : BFD_RELOC_SPARC_JMP_SLOT - : BFD_RELOC_SPARC_RELATIVE - : BFD_RELOC_SPARC_UA32 SPARC ELF relocations. There is probably some overlap with other relocation types already defined. - : BFD_RELOC_SPARC_BASE13 - : BFD_RELOC_SPARC_BASE22 I think these are specific to SPARC a.out (e.g., Sun 4). - : BFD_RELOC_SPARC_64 - : BFD_RELOC_SPARC_10 - : BFD_RELOC_SPARC_11 - : BFD_RELOC_SPARC_OLO10 - : BFD_RELOC_SPARC_HH22 - : BFD_RELOC_SPARC_HM10 - : BFD_RELOC_SPARC_LM22 - : BFD_RELOC_SPARC_PC_HH22 - : BFD_RELOC_SPARC_PC_HM10 - : BFD_RELOC_SPARC_PC_LM22 - : BFD_RELOC_SPARC_WDISP16 - : BFD_RELOC_SPARC_WDISP19 - : BFD_RELOC_SPARC_7 - : BFD_RELOC_SPARC_6 - : BFD_RELOC_SPARC_5 - : BFD_RELOC_SPARC_DISP64 - : BFD_RELOC_SPARC_PLT64 - : BFD_RELOC_SPARC_HIX22 - : BFD_RELOC_SPARC_LOX10 - : BFD_RELOC_SPARC_H44 - : BFD_RELOC_SPARC_M44 - : BFD_RELOC_SPARC_L44 - : BFD_RELOC_SPARC_REGISTER SPARC64 relocations - : BFD_RELOC_ALPHA_GPDISP_HI16 Alpha ECOFF and ELF relocations. Some of these treat the symbol or "addend" in some special way. For GPDISP_HI16 ("gpdisp") relocations, the symbol is ignored when writing; when reading, it will be the absolute section symbol. The addend is the displacement in bytes of the "lda" instruction from the "ldah" instruction (which is at the address of this reloc). - : BFD_RELOC_ALPHA_GPDISP_LO16 For GPDISP_LO16 ("ignore") relocations, the symbol is handled as with GPDISP_HI16 relocs. The addend is ignored when writing the relocations out, and is filled in with the file's GP value on reading, for convenience. - : BFD_RELOC_ALPHA_GPDISP The ELF GPDISP relocation is exactly the same as the GPDISP_HI16 relocation except that there is no accompanying GPDISP_LO16 relocation. - : BFD_RELOC_ALPHA_LITERAL - : BFD_RELOC_ALPHA_ELF_LITERAL - : BFD_RELOC_ALPHA_LITUSE The Alpha LITERAL/LITUSE relocs are produced by a symbol reference; the assembler turns it into a LDQ instruction to load the address of the symbol, and then fills in a register in the real instruction. The LITERAL reloc, at the LDQ instruction, refers to the .lita section symbol. The addend is ignored when writing, but is filled in with the file's GP value on reading, for convenience, as with the GPDISP_LO16 reloc. The ELF_LITERAL reloc is somewhere between 16_GOTOFF and GPDISP_LO16. It should refer to the symbol to be referenced, as with 16_GOTOFF, but it generates output not based on the position within the .got section, but relative to the GP value chosen for the file during the final link stage. The LITUSE reloc, on the instruction using the loaded address, gives information to the linker that it might be able to use to optimize away some literal section references. The symbol is ignored (read as the absolute section symbol), and the "addend" indicates the type of instruction using the register: 1 - "memory" fmt insn 2 - byte-manipulation (byte offset reg) 3 - jsr (target of branch) The GNU linker currently doesn't do any of this optimizing. - : BFD_RELOC_ALPHA_HINT The HINT relocation indicates a value that should be filled into the "hint" field of a jmp/jsr/ret instruction, for possible branch- prediction logic which may be provided on some processors. - : BFD_RELOC_ALPHA_LINKAGE The LINKAGE relocation outputs a linkage pair in the object file, which is filled by the linker. - : BFD_RELOC_ALPHA_CODEADDR The CODEADDR relocation outputs a STO_CA in the object file, which is filled by the linker. - : BFD_RELOC_MIPS_JMP Bits 27..2 of the relocation address shifted right 2 bits; simple reloc otherwise. - : BFD_RELOC_MIPS16_JMP The MIPS16 jump instruction. - : BFD_RELOC_MIPS16_GPREL MIPS16 GP relative reloc. - : BFD_RELOC_HI16 High 16 bits of 32-bit value; simple reloc. - : BFD_RELOC_HI16_S High 16 bits of 32-bit value but the low 16 bits will be sign extended and added to form the final result. If the low 16 bits form a negative number, we need to add one to the high value to compensate for the borrow when the low bits are added. - : BFD_RELOC_LO16 Low 16 bits. - : BFD_RELOC_PCREL_HI16_S Like BFD_RELOC_HI16_S, but PC relative. - : BFD_RELOC_PCREL_LO16 Like BFD_RELOC_LO16, but PC relative. - : BFD_RELOC_MIPS_GPREL Relocation relative to the global pointer. - : BFD_RELOC_MIPS_LITERAL Relocation against a MIPS literal section. - : BFD_RELOC_MIPS_GOT16 - : BFD_RELOC_MIPS_CALL16 - : BFD_RELOC_MIPS_GPREL32 - : BFD_RELOC_MIPS_GOT_HI16 - : BFD_RELOC_MIPS_GOT_LO16 - : BFD_RELOC_MIPS_CALL_HI16 - : BFD_RELOC_MIPS_CALL_LO16 MIPS ELF relocations. - : BFD_RELOC_386_GOT32 - : BFD_RELOC_386_PLT32 - : BFD_RELOC_386_COPY - : BFD_RELOC_386_GLOB_DAT - : BFD_RELOC_386_JUMP_SLOT - : BFD_RELOC_386_RELATIVE - : BFD_RELOC_386_GOTOFF - : BFD_RELOC_386_GOTPC i386/elf relocations - : BFD_RELOC_NS32K_IMM_8 - : BFD_RELOC_NS32K_IMM_16 - : BFD_RELOC_NS32K_IMM_32 - : BFD_RELOC_NS32K_IMM_8_PCREL - : BFD_RELOC_NS32K_IMM_16_PCREL - : BFD_RELOC_NS32K_IMM_32_PCREL - : BFD_RELOC_NS32K_DISP_8 - : BFD_RELOC_NS32K_DISP_16 - : BFD_RELOC_NS32K_DISP_32 - : BFD_RELOC_NS32K_DISP_8_PCREL - : BFD_RELOC_NS32K_DISP_16_PCREL - : BFD_RELOC_NS32K_DISP_32_PCREL ns32k relocations - : BFD_RELOC_PPC_B26 - : BFD_RELOC_PPC_BA26 - : BFD_RELOC_PPC_TOC16 - : BFD_RELOC_PPC_B16 - : BFD_RELOC_PPC_B16_BRTAKEN - : BFD_RELOC_PPC_B16_BRNTAKEN - : BFD_RELOC_PPC_BA16 - : BFD_RELOC_PPC_BA16_BRTAKEN - : BFD_RELOC_PPC_BA16_BRNTAKEN - : BFD_RELOC_PPC_COPY - : BFD_RELOC_PPC_GLOB_DAT - : BFD_RELOC_PPC_JMP_SLOT - : BFD_RELOC_PPC_RELATIVE - : BFD_RELOC_PPC_LOCAL24PC - : BFD_RELOC_PPC_EMB_NADDR32 - : BFD_RELOC_PPC_EMB_NADDR16 - : BFD_RELOC_PPC_EMB_NADDR16_LO - : BFD_RELOC_PPC_EMB_NADDR16_HI - : BFD_RELOC_PPC_EMB_NADDR16_HA - : BFD_RELOC_PPC_EMB_SDAI16 - : BFD_RELOC_PPC_EMB_SDA2I16 - : BFD_RELOC_PPC_EMB_SDA2REL - : BFD_RELOC_PPC_EMB_SDA21 - : BFD_RELOC_PPC_EMB_MRKREF - : BFD_RELOC_PPC_EMB_RELSEC16 - : BFD_RELOC_PPC_EMB_RELST_LO - : BFD_RELOC_PPC_EMB_RELST_HI - : BFD_RELOC_PPC_EMB_RELST_HA - : BFD_RELOC_PPC_EMB_BIT_FLD - : BFD_RELOC_PPC_EMB_RELSDA Power(rs6000) and PowerPC relocations. - : BFD_RELOC_CTOR The type of reloc used to build a contructor table - at the moment probably a 32 bit wide absolute relocation, but the target can choose. It generally does map to one of the other relocation types. - : BFD_RELOC_ARM_PCREL_BRANCH ARM 26 bit pc-relative branch. The lowest two bits must be zero and are not stored in the instruction. - : BFD_RELOC_ARM_IMMEDIATE - : BFD_RELOC_ARM_OFFSET_IMM - : BFD_RELOC_ARM_SHIFT_IMM - : BFD_RELOC_ARM_SWI - : BFD_RELOC_ARM_MULTI - : BFD_RELOC_ARM_CP_OFF_IMM - : BFD_RELOC_ARM_ADR_IMM - : BFD_RELOC_ARM_LDR_IMM - : BFD_RELOC_ARM_LITERAL - : BFD_RELOC_ARM_IN_POOL - : BFD_RELOC_ARM_OFFSET_IMM8 - : BFD_RELOC_ARM_HWLITERAL - : BFD_RELOC_ARM_THUMB_ADD - : BFD_RELOC_ARM_THUMB_IMM - : BFD_RELOC_ARM_THUMB_SHIFT - : BFD_RELOC_ARM_THUMB_OFFSET These relocs are only used within the ARM assembler. They are not (at present) written to any object files. - : BFD_RELOC_SH_PCDISP8BY2 - : BFD_RELOC_SH_PCDISP12BY2 - : BFD_RELOC_SH_IMM4 - : BFD_RELOC_SH_IMM4BY2 - : BFD_RELOC_SH_IMM4BY4 - : BFD_RELOC_SH_IMM8 - : BFD_RELOC_SH_IMM8BY2 - : BFD_RELOC_SH_IMM8BY4 - : BFD_RELOC_SH_PCRELIMM8BY2 - : BFD_RELOC_SH_PCRELIMM8BY4 - : BFD_RELOC_SH_SWITCH16 - : BFD_RELOC_SH_SWITCH32 - : BFD_RELOC_SH_USES - : BFD_RELOC_SH_COUNT - : BFD_RELOC_SH_ALIGN - : BFD_RELOC_SH_CODE - : BFD_RELOC_SH_DATA - : BFD_RELOC_SH_LABEL Hitachi SH relocs. Not all of these appear in object files. - : BFD_RELOC_THUMB_PCREL_BRANCH9 - : BFD_RELOC_THUMB_PCREL_BRANCH12 - : BFD_RELOC_THUMB_PCREL_BRANCH23 Thumb 23-, 12- and 9-bit pc-relative branches. The lowest bit must be zero and is not stored in the instruction. - : BFD_RELOC_ARC_B22_PCREL Argonaut RISC Core (ARC) relocs. ARC 22 bit pc-relative branch. The lowest two bits must be zero and are not stored in the instruction. The high 20 bits are installed in bits 26 through 7 of the instruction. - : BFD_RELOC_ARC_B26 ARC 26 bit absolute branch. The lowest two bits must be zero and are not stored in the instruction. The high 24 bits are installed in bits 23 through 0. - : BFD_RELOC_D10V_10_PCREL_R Mitsubishi D10V relocs. This is a 10-bit reloc with the right 2 bits assumed to be 0. - : BFD_RELOC_D10V_10_PCREL_L Mitsubishi D10V relocs. This is a 10-bit reloc with the right 2 bits assumed to be 0. This is the same as the previous reloc except it is in the left container, i.e., shifted left 15 bits. - : BFD_RELOC_D10V_18 This is an 18-bit reloc with the right 2 bits assumed to be 0. - : BFD_RELOC_D10V_18_PCREL This is an 18-bit reloc with the right 2 bits assumed to be 0. - : BFD_RELOC_M32R_24 Mitsubishi M32R relocs. This is a 24 bit absolute address. - : BFD_RELOC_M32R_10_PCREL This is a 10-bit pc-relative reloc with the right 2 bits assumed to be 0. - : BFD_RELOC_M32R_18_PCREL This is an 18-bit reloc with the right 2 bits assumed to be 0. - : BFD_RELOC_M32R_26_PCREL This is a 26-bit reloc with the right 2 bits assumed to be 0. - : BFD_RELOC_M32R_HI16_ULO This is a 16-bit reloc containing the high 16 bits of an address used when the lower 16 bits are treated as unsigned. - : BFD_RELOC_M32R_HI16_SLO This is a 16-bit reloc containing the high 16 bits of an address used when the lower 16 bits are treated as signed. - : BFD_RELOC_M32R_LO16 This is a 16-bit reloc containing the lower 16 bits of an address. - : BFD_RELOC_M32R_SDA16 This is a 16-bit reloc containing the small data area offset for use in add3, load, and store instructions. - : BFD_RELOC_V850_9_PCREL This is a 9-bit reloc - : BFD_RELOC_V850_22_PCREL This is a 22-bit reloc - : BFD_RELOC_V850_SDA_16_16_OFFSET This is a 16 bit offset from the short data area pointer. - : BFD_RELOC_V850_SDA_15_16_OFFSET This is a 16 bit offset (of which only 15 bits are used) from the short data area pointer. - : BFD_RELOC_V850_ZDA_16_16_OFFSET This is a 16 bit offset from the zero data area pointer. - : BFD_RELOC_V850_ZDA_15_16_OFFSET This is a 16 bit offset (of which only 15 bits are used) from the zero data area pointer. - : BFD_RELOC_V850_TDA_6_8_OFFSET This is an 8 bit offset (of which only 6 bits are used) from the tiny data area pointer. - : BFD_RELOC_V850_TDA_7_8_OFFSET This is an 8bit offset (of which only 7 bits are used) from the tiny data area pointer. - : BFD_RELOC_V850_TDA_7_7_OFFSET This is a 7 bit offset from the tiny data area pointer. - : BFD_RELOC_V850_TDA_16_16_OFFSET This is a 16 bit offset from the tiny data area pointer. - : BFD_RELOC_MN10300_32_PCREL This is a 32bit pcrel reloc for the mn10300, offset by two bytes in the instruction. - : BFD_RELOC_MN10300_16_PCREL This is a 16bit pcrel reloc for the mn10300, offset by two bytes in the instruction. - : BFD_RELOC_TIC30_LDP This is a 8bit DP reloc for the tms320c30, where the most significant 8 bits of a 24 bit word are placed into the least significant 8 bits of the opcode. typedef enum bfd_reloc_code_real bfd_reloc_code_real_type; `bfd_reloc_type_lookup' ....................... *Synopsis* reloc_howto_type * bfd_reloc_type_lookup (bfd *abfd, bfd_reloc_code_real_type code); *Description* Return a pointer to a howto structure which, when invoked, will perform the relocation CODE on data from the architecture noted. `bfd_default_reloc_type_lookup' ............................... *Synopsis* reloc_howto_type *bfd_default_reloc_type_lookup (bfd *abfd, bfd_reloc_code_real_type code); *Description* Provides a default relocation lookup routine for any architecture. `bfd_get_reloc_code_name' ......................... *Synopsis* const char *bfd_get_reloc_code_name (bfd_reloc_code_real_type code); *Description* Provides a printable name for the supplied relocation code. Useful mainly for printing error messages. `bfd_generic_relax_section' ........................... *Synopsis* boolean bfd_generic_relax_section (bfd *abfd, asection *section, struct bfd_link_info *, boolean *); *Description* Provides default handling for relaxing for back ends which don't do relaxing - i.e., does nothing. `bfd_generic_get_relocated_section_contents' ............................................ *Synopsis* bfd_byte * bfd_generic_get_relocated_section_contents (bfd *abfd, struct bfd_link_info *link_info, struct bfd_link_order *link_order, bfd_byte *data, boolean relocateable, asymbol **symbols); *Description* Provides default handling of relocation effort for back ends which can't be bothered to do it efficiently. Core files ========== *Description* These are functions pertaining to core files. `bfd_core_file_failing_command' ............................... *Synopsis* CONST char *bfd_core_file_failing_command(bfd *abfd); *Description* Return a read-only string explaining which program was running when it failed and produced the core file ABFD. `bfd_core_file_failing_signal' .............................. *Synopsis* int bfd_core_file_failing_signal(bfd *abfd); *Description* Returns the signal number which caused the core dump which generated the file the BFD ABFD is attached to. `core_file_matches_executable_p' ................................ *Synopsis* boolean core_file_matches_executable_p (bfd *core_bfd, bfd *exec_bfd); *Description* Return `true' if the core file attached to CORE_BFD was generated by a run of the executable file attached to EXEC_BFD, `false' otherwise. Targets ======= *Description* Each port of BFD to a different machine requries the creation of a target back end. All the back end provides to the root part of BFD is a structure containing pointers to functions which perform certain low level operations on files. BFD translates the applications's requests through a pointer into calls to the back end routines. When a file is opened with `bfd_openr', its format and target are unknown. BFD uses various mechanisms to determine how to interpret the file. The operations performed are: * Create a BFD by calling the internal routine `_bfd_new_bfd', then call `bfd_find_target' with the target string supplied to `bfd_openr' and the new BFD pointer. * If a null target string was provided to `bfd_find_target', look up the environment variable `GNUTARGET' and use that as the target string. * If the target string is still `NULL', or the target string is `default', then use the first item in the target vector as the target type, and set `target_defaulted' in the BFD to cause `bfd_check_format' to loop through all the targets. *Note bfd_target::. *Note Formats::. * Otherwise, inspect the elements in the target vector one by one, until a match on target name is found. When found, use it. * Otherwise return the error `bfd_error_invalid_target' to `bfd_openr'. * `bfd_openr' attempts to open the file using `bfd_open_file', and returns the BFD. Once the BFD has been opened and the target selected, the file format may be determined. This is done by calling `bfd_check_format' on the BFD with a suggested format. If `target_defaulted' has been set, each possible target type is tried to see if it recognizes the specified format. `bfd_check_format' returns `true' when the caller guesses right. bfd_target ---------- *Description* This structure contains everything that BFD knows about a target. It includes things like its byte order, name, and which routines to call to do various operations. Every BFD points to a target structure with its `xvec' member. The macros below are used to dispatch to functions through the `bfd_target' vector. They are used in a number of macros further down in `bfd.h', and are also used when calling various routines by hand inside the BFD implementation. The ARGLIST argument must be parenthesized; it contains all the arguments to the called function. They make the documentation (more) unpleasant to read, so if someone wants to fix this and not break the above, please do. #define BFD_SEND(bfd, message, arglist) \ ((*((bfd)->xvec->message)) arglist) #ifdef DEBUG_BFD_SEND #undef BFD_SEND #define BFD_SEND(bfd, message, arglist) \ (((bfd) && (bfd)->xvec && (bfd)->xvec->message) ? \ ((*((bfd)->xvec->message)) arglist) : \ (bfd_assert (__FILE__,__LINE__), NULL)) #endif For operations which index on the BFD format: #define BFD_SEND_FMT(bfd, message, arglist) \ (((bfd)->xvec->message[(int)((bfd)->format)]) arglist) #ifdef DEBUG_BFD_SEND #undef BFD_SEND_FMT #define BFD_SEND_FMT(bfd, message, arglist) \ (((bfd) && (bfd)->xvec && (bfd)->xvec->message) ? \ (((bfd)->xvec->message[(int)((bfd)->format)]) arglist) : \ (bfd_assert (__FILE__,__LINE__), NULL)) #endif This is the structure which defines the type of BFD this is. The `xvec' member of the struct `bfd' itself points here. Each module that implements access to a different target under BFD, defines one of these. FIXME, these names should be rationalised with the names of the entry points which call them. Too bad we can't have one macro to define them both! enum bfd_flavour { bfd_target_unknown_flavour, bfd_target_aout_flavour, bfd_target_coff_flavour, bfd_target_ecoff_flavour, bfd_target_elf_flavour, bfd_target_ieee_flavour, bfd_target_nlm_flavour, bfd_target_oasys_flavour, bfd_target_tekhex_flavour, bfd_target_srec_flavour, bfd_target_ihex_flavour, bfd_target_som_flavour, bfd_target_os9k_flavour, bfd_target_versados_flavour, bfd_target_msdos_flavour, bfd_target_evax_flavour }; enum bfd_endian { BFD_ENDIAN_BIG, BFD_ENDIAN_LITTLE, BFD_ENDIAN_UNKNOWN }; /* Forward declaration. */ typedef struct bfd_link_info _bfd_link_info; typedef struct bfd_target { Identifies the kind of target, e.g., SunOS4, Ultrix, etc. char *name; The "flavour" of a back end is a general indication about the contents of a file. enum bfd_flavour flavour; The order of bytes within the data area of a file. enum bfd_endian byteorder; The order of bytes within the header parts of a file. enum bfd_endian header_byteorder; A mask of all the flags which an executable may have set - from the set `BFD_NO_FLAGS', `HAS_RELOC', ...`D_PAGED'. flagword object_flags; A mask of all the flags which a section may have set - from the set `SEC_NO_FLAGS', `SEC_ALLOC', ...`SET_NEVER_LOAD'. flagword section_flags; The character normally found at the front of a symbol (if any), perhaps `_'. char symbol_leading_char; The pad character for file names within an archive header. char ar_pad_char; The maximum number of characters in an archive header. unsigned short ar_max_namelen; Entries for byte swapping for data. These are different from the other entry points, since they don't take a BFD asthe first argument. Certain other handlers could do the same. bfd_vma (*bfd_getx64) PARAMS ((const bfd_byte *)); bfd_signed_vma (*bfd_getx_signed_64) PARAMS ((const bfd_byte *)); void (*bfd_putx64) PARAMS ((bfd_vma, bfd_byte *)); bfd_vma (*bfd_getx32) PARAMS ((const bfd_byte *)); bfd_signed_vma (*bfd_getx_signed_32) PARAMS ((const bfd_byte *)); void (*bfd_putx32) PARAMS ((bfd_vma, bfd_byte *)); bfd_vma (*bfd_getx16) PARAMS ((const bfd_byte *)); bfd_signed_vma (*bfd_getx_signed_16) PARAMS ((const bfd_byte *)); void (*bfd_putx16) PARAMS ((bfd_vma, bfd_byte *)); Byte swapping for the headers bfd_vma (*bfd_h_getx64) PARAMS ((const bfd_byte *)); bfd_signed_vma (*bfd_h_getx_signed_64) PARAMS ((const bfd_byte *)); void (*bfd_h_putx64) PARAMS ((bfd_vma, bfd_byte *)); bfd_vma (*bfd_h_getx32) PARAMS ((const bfd_byte *)); bfd_signed_vma (*bfd_h_getx_signed_32) PARAMS ((const bfd_byte *)); void (*bfd_h_putx32) PARAMS ((bfd_vma, bfd_byte *)); bfd_vma (*bfd_h_getx16) PARAMS ((const bfd_byte *)); bfd_signed_vma (*bfd_h_getx_signed_16) PARAMS ((const bfd_byte *)); void (*bfd_h_putx16) PARAMS ((bfd_vma, bfd_byte *)); Format dependent routines: these are vectors of entry points within the target vector structure, one for each format to check. Check the format of a file being read. Return a `bfd_target *' or zero. const struct bfd_target *(*_bfd_check_format[bfd_type_end]) PARAMS ((bfd *)); Set the format of a file being written. boolean (*_bfd_set_format[bfd_type_end]) PARAMS ((bfd *)); Write cached information into a file being written, at `bfd_close'. boolean (*_bfd_write_contents[bfd_type_end]) PARAMS ((bfd *)); The general target vector. /* Generic entry points. */ #define BFD_JUMP_TABLE_GENERIC(NAME)\ CAT(NAME,_close_and_cleanup),\ CAT(NAME,_bfd_free_cached_info),\ CAT(NAME,_new_section_hook),\ CAT(NAME,_get_section_contents),\ CAT(NAME,_get_section_contents_in_window) /* Called when the BFD is being closed to do any necessary cleanup. */ boolean (*_close_and_cleanup) PARAMS ((bfd *)); /* Ask the BFD to free all cached information. */ boolean (*_bfd_free_cached_info) PARAMS ((bfd *)); /* Called when a new section is created. */ boolean (*_new_section_hook) PARAMS ((bfd *, sec_ptr)); /* Read the contents of a section. */ boolean (*_bfd_get_section_contents) PARAMS ((bfd *, sec_ptr, PTR, file_ptr, bfd_size_type)); boolean (*_bfd_get_section_contents_in_window) PARAMS ((bfd *, sec_ptr, bfd_window *, file_ptr, bfd_size_type)); /* Entry points to copy private data. */ #define BFD_JUMP_TABLE_COPY(NAME)\ CAT(NAME,_bfd_copy_private_bfd_data),\ CAT(NAME,_bfd_merge_private_bfd_data),\ CAT(NAME,_bfd_copy_private_section_data),\ CAT(NAME,_bfd_copy_private_symbol_data),\ CAT(NAME,_bfd_set_private_flags),\ CAT(NAME,_bfd_print_private_bfd_data)\ /* Called to copy BFD general private data from one object file to another. */ boolean (*_bfd_copy_private_bfd_data) PARAMS ((bfd *, bfd *)); /* Called to merge BFD general private data from one object file to a common output file when linking. */ boolean (*_bfd_merge_private_bfd_data) PARAMS ((bfd *, bfd *)); /* Called to copy BFD private section data from one object file to another. */ boolean (*_bfd_copy_private_section_data) PARAMS ((bfd *, sec_ptr, bfd *, sec_ptr)); /* Called to copy BFD private symbol data from one symbol to another. */ boolean (*_bfd_copy_private_symbol_data) PARAMS ((bfd *, asymbol *, bfd *, asymbol *)); /* Called to set private backend flags */ boolean (*_bfd_set_private_flags) PARAMS ((bfd *, flagword)); /* Called to print private BFD data */ boolean (*_bfd_print_private_bfd_data) PARAMS ((bfd *, PTR)); /* Core file entry points. */ #define BFD_JUMP_TABLE_CORE(NAME)\ CAT(NAME,_core_file_failing_command),\ CAT(NAME,_core_file_failing_signal),\ CAT(NAME,_core_file_matches_executable_p) char * (*_core_file_failing_command) PARAMS ((bfd *)); int (*_core_file_failing_signal) PARAMS ((bfd *)); boolean (*_core_file_matches_executable_p) PARAMS ((bfd *, bfd *)); /* Archive entry points. */ #define BFD_JUMP_TABLE_ARCHIVE(NAME)\ CAT(NAME,_slurp_armap),\ CAT(NAME,_slurp_extended_name_table),\ CAT(NAME,_construct_extended_name_table),\ CAT(NAME,_truncate_arname),\ CAT(NAME,_write_armap),\ CAT(NAME,_read_ar_hdr),\ CAT(NAME,_openr_next_archived_file),\ CAT(NAME,_get_elt_at_index),\ CAT(NAME,_generic_stat_arch_elt),\ CAT(NAME,_update_armap_timestamp) boolean (*_bfd_slurp_armap) PARAMS ((bfd *)); boolean (*_bfd_slurp_extended_name_table) PARAMS ((bfd *)); boolean (*_bfd_construct_extended_name_table) PARAMS ((bfd *, char **, bfd_size_type *, const char **)); void (*_bfd_truncate_arname) PARAMS ((bfd *, CONST char *, char *)); boolean (*write_armap) PARAMS ((bfd *arch, unsigned int elength, struct orl *map, unsigned int orl_count, int stridx)); PTR (*_bfd_read_ar_hdr_fn) PARAMS ((bfd *)); bfd * (*openr_next_archived_file) PARAMS ((bfd *arch, bfd *prev)); #define bfd_get_elt_at_index(b,i) BFD_SEND(b, _bfd_get_elt_at_index, (b,i)) bfd * (*_bfd_get_elt_at_index) PARAMS ((bfd *, symindex)); int (*_bfd_stat_arch_elt) PARAMS ((bfd *, struct stat *)); boolean (*_bfd_update_armap_timestamp) PARAMS ((bfd *)); /* Entry points used for symbols. */ #define BFD_JUMP_TABLE_SYMBOLS(NAME)\ CAT(NAME,_get_symtab_upper_bound),\ CAT(NAME,_get_symtab),\ CAT(NAME,_make_empty_symbol),\ CAT(NAME,_print_symbol),\ CAT(NAME,_get_symbol_info),\ CAT(NAME,_bfd_is_local_label_name),\ CAT(NAME,_get_lineno),\ CAT(NAME,_find_nearest_line),\ CAT(NAME,_bfd_make_debug_symbol),\ CAT(NAME,_read_minisymbols),\ CAT(NAME,_minisymbol_to_symbol) long (*_bfd_get_symtab_upper_bound) PARAMS ((bfd *)); long (*_bfd_canonicalize_symtab) PARAMS ((bfd *, struct symbol_cache_entry **)); struct symbol_cache_entry * (*_bfd_make_empty_symbol) PARAMS ((bfd *)); void (*_bfd_print_symbol) PARAMS ((bfd *, PTR, struct symbol_cache_entry *, bfd_print_symbol_type)); #define bfd_print_symbol(b,p,s,e) BFD_SEND(b, _bfd_print_symbol, (b,p,s,e)) void (*_bfd_get_symbol_info) PARAMS ((bfd *, struct symbol_cache_entry *, symbol_info *)); #define bfd_get_symbol_info(b,p,e) BFD_SEND(b, _bfd_get_symbol_info, (b,p,e)) boolean (*_bfd_is_local_label_name) PARAMS ((bfd *, const char *)); alent * (*_get_lineno) PARAMS ((bfd *, struct symbol_cache_entry *)); boolean (*_bfd_find_nearest_line) PARAMS ((bfd *abfd, struct sec *section, struct symbol_cache_entry **symbols, bfd_vma offset, CONST char **file, CONST char **func, unsigned int *line)); /* Back-door to allow format-aware applications to create debug symbols while using BFD for everything else. Currently used by the assembler when creating COFF files. */ asymbol * (*_bfd_make_debug_symbol) PARAMS (( bfd *abfd, void *ptr, unsigned long size)); #define bfd_read_minisymbols(b, d, m, s) \ BFD_SEND (b, _read_minisymbols, (b, d, m, s)) long (*_read_minisymbols) PARAMS ((bfd *, boolean, PTR *, unsigned int *)); #define bfd_minisymbol_to_symbol(b, d, m, f) \ BFD_SEND (b, _minisymbol_to_symbol, (b, d, m, f)) asymbol *(*_minisymbol_to_symbol) PARAMS ((bfd *, boolean, const PTR, asymbol *)); /* Routines for relocs. */ #define BFD_JUMP_TABLE_RELOCS(NAME)\ CAT(NAME,_get_reloc_upper_bound),\ CAT(NAME,_canonicalize_reloc),\ CAT(NAME,_bfd_reloc_type_lookup) long (*_get_reloc_upper_bound) PARAMS ((bfd *, sec_ptr)); long (*_bfd_canonicalize_reloc) PARAMS ((bfd *, sec_ptr, arelent **, struct symbol_cache_entry **)); /* See documentation on reloc types. */ reloc_howto_type * (*reloc_type_lookup) PARAMS ((bfd *abfd, bfd_reloc_code_real_type code)); /* Routines used when writing an object file. */ #define BFD_JUMP_TABLE_WRITE(NAME)\ CAT(NAME,_set_arch_mach),\ CAT(NAME,_set_section_contents) boolean (*_bfd_set_arch_mach) PARAMS ((bfd *, enum bfd_architecture, unsigned long)); boolean (*_bfd_set_section_contents) PARAMS ((bfd *, sec_ptr, PTR, file_ptr, bfd_size_type)); /* Routines used by the linker. */ #define BFD_JUMP_TABLE_LINK(NAME)\ CAT(NAME,_sizeof_headers),\ CAT(NAME,_bfd_get_relocated_section_contents),\ CAT(NAME,_bfd_relax_section),\ CAT(NAME,_bfd_link_hash_table_create),\ CAT(NAME,_bfd_link_add_symbols),\ CAT(NAME,_bfd_final_link),\ CAT(NAME,_bfd_link_split_section) int (*_bfd_sizeof_headers) PARAMS ((bfd *, boolean)); bfd_byte * (*_bfd_get_relocated_section_contents) PARAMS ((bfd *, struct bfd_link_info *, struct bfd_link_order *, bfd_byte *data, boolean relocateable, struct symbol_cache_entry **)); boolean (*_bfd_relax_section) PARAMS ((bfd *, struct sec *, struct bfd_link_info *, boolean *again)); /* Create a hash table for the linker. Different backends store different information in this table. */ struct bfd_link_hash_table *(*_bfd_link_hash_table_create) PARAMS ((bfd *)); /* Add symbols from this object file into the hash table. */ boolean (*_bfd_link_add_symbols) PARAMS ((bfd *, struct bfd_link_info *)); /* Do a link based on the link_order structures attached to each section of the BFD. */ boolean (*_bfd_final_link) PARAMS ((bfd *, struct bfd_link_info *)); /* Should this section be split up into smaller pieces during linking. */ boolean (*_bfd_link_split_section) PARAMS ((bfd *, struct sec *)); /* Routines to handle dynamic symbols and relocs. */ #define BFD_JUMP_TABLE_DYNAMIC(NAME)\ CAT(NAME,_get_dynamic_symtab_upper_bound),\ CAT(NAME,_canonicalize_dynamic_symtab),\ CAT(NAME,_get_dynamic_reloc_upper_bound),\ CAT(NAME,_canonicalize_dynamic_reloc) /* Get the amount of memory required to hold the dynamic symbols. */ long (*_bfd_get_dynamic_symtab_upper_bound) PARAMS ((bfd *)); /* Read in the dynamic symbols. */ long (*_bfd_canonicalize_dynamic_symtab) PARAMS ((bfd *, struct symbol_cache_entry **)); /* Get the amount of memory required to hold the dynamic relocs. */ long (*_bfd_get_dynamic_reloc_upper_bound) PARAMS ((bfd *)); /* Read in the dynamic relocs. */ long (*_bfd_canonicalize_dynamic_reloc) PARAMS ((bfd *, arelent **, struct symbol_cache_entry **)); Data for use by back-end routines, which isn't generic enough to belong in this structure. PTR backend_data; } bfd_target; `bfd_set_default_target' ........................ *Synopsis* boolean bfd_set_default_target (const char *name); *Description* Set the default target vector to use when recognizing a BFD. This takes the name of the target, which may be a BFD target name or a configuration triplet. `bfd_find_target' ................. *Synopsis* const bfd_target *bfd_find_target(CONST char *target_name, bfd *abfd); *Description* Return a pointer to the transfer vector for the object target named TARGET_NAME. If TARGET_NAME is `NULL', choose the one in the environment variable `GNUTARGET'; if that is null or not defined, then choose the first entry in the target list. Passing in the string "default" or setting the environment variable to "default" will cause the first entry in the target list to be returned, and "target_defaulted" will be set in the BFD. This causes `bfd_check_format' to loop over all the targets to find the one that matches the file being read. `bfd_target_list' ................. *Synopsis* const char **bfd_target_list(void); *Description* Return a freshly malloced NULL-terminated vector of the names of all the valid BFD targets. Do not modify the names. Architectures ============= BFD keeps one atom in a BFD describing the architecture of the data attached to the BFD: a pointer to a `bfd_arch_info_type'. Pointers to structures can be requested independently of a BFD so that an architecture's information can be interrogated without access to an open BFD. The architecture information is provided by each architecture package. The set of default architectures is selected by the macro `SELECT_ARCHITECTURES'. This is normally set up in the `config/TARGET.mt' file of your choice. If the name is not defined, then all the architectures supported are included. When BFD starts up, all the architectures are called with an initialize method. It is up to the architecture back end to insert as many items into the list of architectures as it wants to; generally this would be one for each machine and one for the default case (an item with a machine field of 0). BFD's idea of an architecture is implemented in `archures.c'. bfd_architecture ---------------- *Description* This enum gives the object file's CPU architecture, in a global sense--i.e., what processor family does it belong to? Another field indicates which processor within the family is in use. The machine gives a number which distinguishes different versions of the architecture, containing, for example, 2 and 3 for Intel i960 KA and i960 KB, and 68020 and 68030 for Motorola 68020 and 68030. enum bfd_architecture { bfd_arch_unknown, /* File arch not known */ bfd_arch_obscure, /* Arch known, not one of these */ bfd_arch_m68k, /* Motorola 68xxx */ #define bfd_mach_m68000 1 #define bfd_mach_m68008 2 #define bfd_mach_m68010 3 #define bfd_mach_m68020 4 #define bfd_mach_m68030 5 #define bfd_mach_m68040 6 #define bfd_mach_m68060 7 bfd_arch_vax, /* DEC Vax */ bfd_arch_i960, /* Intel 960 */ /* The order of the following is important. lower number indicates a machine type that only accepts a subset of the instructions available to machines with higher numbers. The exception is the "ca", which is incompatible with all other machines except "core". */ #define bfd_mach_i960_core 1 #define bfd_mach_i960_ka_sa 2 #define bfd_mach_i960_kb_sb 3 #define bfd_mach_i960_mc 4 #define bfd_mach_i960_xa 5 #define bfd_mach_i960_ca 6 #define bfd_mach_i960_jx 7 #define bfd_mach_i960_hx 8 bfd_arch_a29k, /* AMD 29000 */ bfd_arch_sparc, /* SPARC */ #define bfd_mach_sparc 1 /* The difference between v8plus and v9 is that v9 is a true 64 bit env. */ #define bfd_mach_sparc_sparclet 2 #define bfd_mach_sparc_sparclite 3 #define bfd_mach_sparc_v8plus 4 #define bfd_mach_sparc_v8plusa 5 /* with ultrasparc add'ns */ #define bfd_mach_sparc_v9 6 #define bfd_mach_sparc_v9a 7 /* with ultrasparc add'ns */ /* Nonzero if MACH has the v9 instruction set. */ #define bfd_mach_sparc_v9_p(mach) \ ((mach) >= bfd_mach_sparc_v8plus && (mach) <= bfd_mach_sparc_v9a) bfd_arch_mips, /* MIPS Rxxxx */ #define bfd_mach_mips3000 300