| 1 | @c This summary of BFD is shared by the BFD and LD docs. |
| 2 | @c Copyright (C) 2012-2015 Free Software Foundation, Inc. |
| 3 | |
| 4 | When an object file is opened, BFD subroutines automatically determine |
| 5 | the format of the input object file. They then build a descriptor in |
| 6 | memory with pointers to routines that will be used to access elements of |
| 7 | the object file's data structures. |
| 8 | |
| 9 | As different information from the object files is required, |
| 10 | BFD reads from different sections of the file and processes them. |
| 11 | For example, a very common operation for the linker is processing symbol |
| 12 | tables. Each BFD back end provides a routine for converting |
| 13 | between the object file's representation of symbols and an internal |
| 14 | canonical format. When the linker asks for the symbol table of an object |
| 15 | file, it calls through a memory pointer to the routine from the |
| 16 | relevant BFD back end which reads and converts the table into a canonical |
| 17 | form. The linker then operates upon the canonical form. When the link is |
| 18 | finished and the linker writes the output file's symbol table, |
| 19 | another BFD back end routine is called to take the newly |
| 20 | created symbol table and convert it into the chosen output format. |
| 21 | |
| 22 | @menu |
| 23 | * BFD information loss:: Information Loss |
| 24 | * Canonical format:: The BFD canonical object-file format |
| 25 | @end menu |
| 26 | |
| 27 | @node BFD information loss |
| 28 | @subsection Information Loss |
| 29 | |
| 30 | @emph{Information can be lost during output.} The output formats |
| 31 | supported by BFD do not provide identical facilities, and |
| 32 | information which can be described in one form has nowhere to go in |
| 33 | another format. One example of this is alignment information in |
| 34 | @code{b.out}. There is nowhere in an @code{a.out} format file to store |
| 35 | alignment information on the contained data, so when a file is linked |
| 36 | from @code{b.out} and an @code{a.out} image is produced, alignment |
| 37 | information will not propagate to the output file. (The linker will |
| 38 | still use the alignment information internally, so the link is performed |
| 39 | correctly). |
| 40 | |
| 41 | Another example is COFF section names. COFF files may contain an |
| 42 | unlimited number of sections, each one with a textual section name. If |
| 43 | the target of the link is a format which does not have many sections (e.g., |
| 44 | @code{a.out}) or has sections without names (e.g., the Oasys format), the |
| 45 | link cannot be done simply. You can circumvent this problem by |
| 46 | describing the desired input-to-output section mapping with the linker command |
| 47 | language. |
| 48 | |
| 49 | @emph{Information can be lost during canonicalization.} The BFD |
| 50 | internal canonical form of the external formats is not exhaustive; there |
| 51 | are structures in input formats for which there is no direct |
| 52 | representation internally. This means that the BFD back ends |
| 53 | cannot maintain all possible data richness through the transformation |
| 54 | between external to internal and back to external formats. |
| 55 | |
| 56 | This limitation is only a problem when an application reads one |
| 57 | format and writes another. Each BFD back end is responsible for |
| 58 | maintaining as much data as possible, and the internal BFD |
| 59 | canonical form has structures which are opaque to the BFD core, |
| 60 | and exported only to the back ends. When a file is read in one format, |
| 61 | the canonical form is generated for BFD and the application. At the |
| 62 | same time, the back end saves away any information which may otherwise |
| 63 | be lost. If the data is then written back in the same format, the back |
| 64 | end routine will be able to use the canonical form provided by the |
| 65 | BFD core as well as the information it prepared earlier. Since |
| 66 | there is a great deal of commonality between back ends, |
| 67 | there is no information lost when |
| 68 | linking or copying big endian COFF to little endian COFF, or @code{a.out} to |
| 69 | @code{b.out}. When a mixture of formats is linked, the information is |
| 70 | only lost from the files whose format differs from the destination. |
| 71 | |
| 72 | @node Canonical format |
| 73 | @subsection The BFD canonical object-file format |
| 74 | |
| 75 | The greatest potential for loss of information occurs when there is the least |
| 76 | overlap between the information provided by the source format, that |
| 77 | stored by the canonical format, and that needed by the |
| 78 | destination format. A brief description of the canonical form may help |
| 79 | you understand which kinds of data you can count on preserving across |
| 80 | conversions. |
| 81 | @cindex BFD canonical format |
| 82 | @cindex internal object-file format |
| 83 | |
| 84 | @table @emph |
| 85 | @item files |
| 86 | Information stored on a per-file basis includes target machine |
| 87 | architecture, particular implementation format type, a demand pageable |
| 88 | bit, and a write protected bit. Information like Unix magic numbers is |
| 89 | not stored here---only the magic numbers' meaning, so a @code{ZMAGIC} |
| 90 | file would have both the demand pageable bit and the write protected |
| 91 | text bit set. The byte order of the target is stored on a per-file |
| 92 | basis, so that big- and little-endian object files may be used with one |
| 93 | another. |
| 94 | |
| 95 | @item sections |
| 96 | Each section in the input file contains the name of the section, the |
| 97 | section's original address in the object file, size and alignment |
| 98 | information, various flags, and pointers into other BFD data |
| 99 | structures. |
| 100 | |
| 101 | @item symbols |
| 102 | Each symbol contains a pointer to the information for the object file |
| 103 | which originally defined it, its name, its value, and various flag |
| 104 | bits. When a BFD back end reads in a symbol table, it relocates all |
| 105 | symbols to make them relative to the base of the section where they were |
| 106 | defined. Doing this ensures that each symbol points to its containing |
| 107 | section. Each symbol also has a varying amount of hidden private data |
| 108 | for the BFD back end. Since the symbol points to the original file, the |
| 109 | private data format for that symbol is accessible. @code{ld} can |
| 110 | operate on a collection of symbols of wildly different formats without |
| 111 | problems. |
| 112 | |
| 113 | Normal global and simple local symbols are maintained on output, so an |
| 114 | output file (no matter its format) will retain symbols pointing to |
| 115 | functions and to global, static, and common variables. Some symbol |
| 116 | information is not worth retaining; in @code{a.out}, type information is |
| 117 | stored in the symbol table as long symbol names. This information would |
| 118 | be useless to most COFF debuggers; the linker has command line switches |
| 119 | to allow users to throw it away. |
| 120 | |
| 121 | There is one word of type information within the symbol, so if the |
| 122 | format supports symbol type information within symbols (for example, COFF, |
| 123 | IEEE, Oasys) and the type is simple enough to fit within one word |
| 124 | (nearly everything but aggregates), the information will be preserved. |
| 125 | |
| 126 | @item relocation level |
| 127 | Each canonical BFD relocation record contains a pointer to the symbol to |
| 128 | relocate to, the offset of the data to relocate, the section the data |
| 129 | is in, and a pointer to a relocation type descriptor. Relocation is |
| 130 | performed by passing messages through the relocation type |
| 131 | descriptor and the symbol pointer. Therefore, relocations can be performed |
| 132 | on output data using a relocation method that is only available in one of the |
| 133 | input formats. For instance, Oasys provides a byte relocation format. |
| 134 | A relocation record requesting this relocation type would point |
| 135 | indirectly to a routine to perform this, so the relocation may be |
| 136 | performed on a byte being written to a 68k COFF file, even though 68k COFF |
| 137 | has no such relocation type. |
| 138 | |
| 139 | @item line numbers |
| 140 | Object formats can contain, for debugging purposes, some form of mapping |
| 141 | between symbols, source line numbers, and addresses in the output file. |
| 142 | These addresses have to be relocated along with the symbol information. |
| 143 | Each symbol with an associated list of line number records points to the |
| 144 | first record of the list. The head of a line number list consists of a |
| 145 | pointer to the symbol, which allows finding out the address of the |
| 146 | function whose line number is being described. The rest of the list is |
| 147 | made up of pairs: offsets into the section and line numbers. Any format |
| 148 | which can simply derive this information can pass it successfully |
| 149 | between formats (COFF, IEEE and Oasys). |
| 150 | @end table |