Commit | Line | Data |
---|---|---|
252b5132 | 1 | @c This summary of BFD is shared by the BFD and LD docs. |
2571583a | 2 | @c Copyright (C) 2012-2017 Free Software Foundation, Inc. |
5bf135a7 | 3 | |
252b5132 RH |
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 | ||
fe032580 | 9 | As different information from the object files is required, |
252b5132 RH |
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 |