Commit | Line | Data |
---|---|---|
80d29884 | 1 | \input texinfo |
a9773c89 | 2 | @setfilename bfd.info |
80d29884 | 3 | @c $Id$ |
a9773c89 | 4 | @synindex fn cp |
80d29884 SC |
5 | @ifinfo |
6 | This file documents the BFD library. | |
7 | ||
8 | Copyright (C) 1991 Free Software Foundation, Inc. | |
9 | ||
10 | Permission is granted to make and distribute verbatim copies of | |
11 | this manual provided the copyright notice and this permission notice | |
12 | are preserved on all copies. | |
13 | ||
14 | @ignore | |
15 | Permission is granted to process this file through Tex and print the | |
16 | results, provided the printed document carries copying permission | |
17 | notice identical to this one except for the removal of this paragraph | |
18 | (this paragraph not being relevant to the printed manual). | |
19 | ||
20 | @end ignore | |
21 | Permission is granted to copy and distribute modified versions of this | |
22 | manual under the conditions for verbatim copying, subject to the terms | |
23 | of the GNU General Public License, which includes the provision that the | |
24 | entire resulting derived work is distributed under the terms of a | |
25 | permission notice identical to this one. | |
26 | ||
27 | Permission is granted to copy and distribute translations of this manual | |
28 | into another language, under the above conditions for modified versions. | |
29 | @end ifinfo | |
30 | @iftex | |
31 | @c@finalout | |
32 | @setchapternewpage on | |
33 | @c@setchapternewpage odd | |
34 | @settitle LIB BFD, the Binary File Descriptor Library | |
35 | @titlepage | |
36 | @title{libbfd} | |
37 | @subtitle{The Binary File Descriptor Library} | |
38 | @sp 1 | |
39 | @subtitle First Edition---BFD version < 2.0 | |
40 | @subtitle April 1991 | |
41 | @author {Steve Chamberlain} | |
42 | @author {Cygnus Support} | |
43 | @page | |
44 | ||
45 | @tex | |
46 | \def\$#1${{#1}} % Kluge: collect RCS revision info without $...$ | |
47 | \xdef\manvers{\$Revision$} % For use in headers, footers too | |
48 | {\parskip=0pt | |
49 | \hfill Cygnus Support\par | |
50 | \hfill steve\@cygnus.com\par | |
51 | \hfill {\it BFD}, \manvers\par | |
52 | \hfill \TeX{}info \texinfoversion\par | |
53 | } | |
54 | \global\parindent=0pt % Steve likes it this way | |
55 | @end tex | |
56 | ||
57 | @vskip 0pt plus 1filll | |
58 | Copyright @copyright{} 1991 Free Software Foundation, Inc. | |
59 | ||
60 | Permission is granted to make and distribute verbatim copies of | |
61 | this manual provided the copyright notice and this permission notice | |
62 | are preserved on all copies. | |
63 | ||
64 | Permission is granted to copy and distribute modified versions of this | |
65 | manual under the conditions for verbatim copying, subject to the terms | |
66 | of the GNU General Public License, which includes the provision that the | |
67 | entire resulting derived work is distributed under the terms of a | |
68 | permission notice identical to this one. | |
69 | ||
70 | Permission is granted to copy and distribute translations of this manual | |
71 | into another language, under the above conditions for modified versions. | |
72 | @end titlepage | |
73 | @end iftex | |
74 | ||
75 | @node Top, Overview, (dir), (dir) | |
76 | @ifinfo | |
77 | This file documents the binary file descriptor library libbfd. | |
78 | @end ifinfo | |
79 | ||
80 | @menu | |
81 | * Overview:: Overview of BFD | |
a9773c89 RP |
82 | * BFD front end:: BFD front end |
83 | * BFD back end:: BFD back end | |
80d29884 | 84 | * Index:: Index |
80d29884 SC |
85 | @end menu |
86 | ||
a9773c89 | 87 | @node Overview, BFD front end, Top, Top |
80d29884 SC |
88 | @chapter Introduction |
89 | @cindex BFD | |
90 | @cindex what is it? | |
91 | Simply put, BFD is a package which allows applications to use the | |
92 | same routines to operate on object files whatever the object file | |
93 | format. A different object file format can be supported simply by | |
94 | creating a new BFD back end and adding it to the library. | |
95 | ||
96 | BFD is split into two parts; the front end and the many back ends. | |
97 | @itemize @bullet | |
98 | @item The front end of BFD provides the interface to the user. It manages | |
99 | memory, and various canonical data structures. The front end also | |
100 | decides which back end to use, and when to call back end routines. | |
101 | @item The back ends provide BFD its view of the real world. Each back | |
102 | end provides a set of calls which the BFD front end can use to maintain | |
103 | its canonical form. The back ends also may keep around information for | |
104 | their own use, for greater efficiency. | |
105 | @end itemize | |
a9773c89 RP |
106 | @menu |
107 | * History:: History | |
108 | * How It Works:: How It Works | |
109 | * What BFD Version 1 Can Do:: What BFD Version 1 Can Do | |
110 | @end menu | |
111 | ||
112 | @node History, How It Works, Overview, Overview | |
80d29884 SC |
113 | @section History |
114 | ||
115 | One spur behind BFD was the desire, on the part of the GNU 960 team at | |
116 | Intel Oregon, for interoperability of applications on their COFF and | |
117 | b.out file formats. Cygnus was providing GNU support for the team, and | |
118 | Cygnus was contracted to provide the required functionality. | |
119 | ||
120 | The name came from a conversation David Wallace was having with Richard | |
121 | Stallman about the library: RMS said that it would be quite hard---David | |
122 | said ``BFD''. Stallman was right, but the name stuck. | |
123 | ||
124 | At the same time, Ready Systems wanted much the same thing, but for | |
125 | different object file formats: IEEE-695, Oasys, Srecords, a.out and 68k | |
126 | coff. | |
127 | ||
128 | BFD was first implemented by Steve Chamberlain (steve@@cygnus.com), | |
129 | John Gilmore (gnu@@cygnus.com), K. Richard Pixley (rich@@cygnus.com) and | |
130 | David Wallace (gumby@@cygnus.com) at Cygnus Support in Palo Alto, | |
131 | California. | |
132 | ||
a9773c89 | 133 | @node How It Works, What BFD Version 1 Can Do, History, Overview |
80d29884 SC |
134 | @section How It Works |
135 | ||
136 | To use the library, include @code{bfd.h} and link with @code{libbfd.a}. | |
137 | ||
138 | BFD provides a common interface to the parts of an object file | |
139 | for a calling application. | |
140 | ||
141 | When an application sucessfully opens a target file (object, archive or | |
142 | whatever) a pointer to an internal structure is returned. This pointer | |
143 | points to a structure called @code{bfd}, described in | |
144 | @code{include/bfd.h}. Our convention is to call this pointer a BFD, and | |
145 | instances of it within code @code{abfd}. All operations on | |
146 | the target object file are applied as methods to the BFD. The mapping is | |
147 | defined within @code{bfd.h} in a set of macros, all beginning | |
148 | @samp{bfd}_. | |
149 | ||
150 | For example, this sequence would do what you would probably expect: | |
151 | return the number of sections in an object file attached to a BFD | |
152 | @code{abfd}. | |
153 | ||
154 | @lisp | |
a9773c89 | 155 | @c @cartouche |
80d29884 SC |
156 | #include "bfd.h" |
157 | ||
158 | unsigned int number_of_sections(abfd) | |
159 | bfd *abfd; | |
160 | @{ | |
161 | return bfd_count_sections(abfd); | |
162 | @} | |
a9773c89 | 163 | @c @end cartouche |
80d29884 SC |
164 | @end lisp |
165 | ||
166 | The abstraction used within BFD is that an object file has a header, | |
167 | a number of sections containing raw data, a set of relocations, and some | |
168 | symbol information. Also, BFDs opened for archives have the | |
169 | additional attribute of an index and contain subordinate BFDs. This approach is | |
170 | fine for a.out and coff, but loses efficiency when applied to formats | |
171 | such as S-records and IEEE-695. | |
172 | ||
a9773c89 | 173 | @node What BFD Version 1 Can Do, , How It Works, Overview |
80d29884 SC |
174 | @section What BFD Version 1 Can Do |
175 | As different information from the the object files is required, | |
176 | BFD reads from different sections of the file and processes them. | |
177 | For example a very common operation for the linker is processing symbol | |
178 | tables. Each BFD back end provides a routine for converting | |
179 | between the object file's representation of symbols and an internal | |
180 | canonical format. When the linker asks for the symbol table of an object | |
181 | file, it calls through the memory pointer to the relevant BFD | |
182 | back end routine which reads and converts the table into a canonical | |
183 | form. The linker then operates upon the canonical form. When the link is | |
184 | finished and the linker writes the output file's symbol table, | |
185 | another BFD back end routine is called which takes the newly | |
186 | created symbol table and converts it into the chosen output format. | |
187 | ||
a9773c89 RP |
188 | @menu |
189 | * BFD information loss:: Information Loss | |
190 | * Mechanism:: Mechanism | |
191 | @end menu | |
192 | ||
193 | @node BFD information loss, Mechanism, What BFD Version 1 Can Do, What BFD Version 1 Can Do | |
80d29884 SC |
194 | @subsection Information Loss |
195 | @emph{Some information is lost due to the nature of the file format.} The output targets | |
196 | supported by BFD do not provide identical facilities, and | |
197 | information which may be described in one form has nowhere to go in | |
198 | another format. One example of this is alignment information in | |
199 | @code{b.out}. There is nowhere in an @code{a.out} format file to store | |
200 | alignment information on the contained data, so when a file is linked | |
201 | from @code{b.out} and an @code{a.out} image is produced, alignment | |
202 | information will not propagate to the output file. (The linker will | |
203 | still use the alignment information internally, so the link is performed | |
204 | correctly). | |
205 | ||
206 | Another example is COFF section names. COFF files may contain an | |
207 | unlimited number of sections, each one with a textual section name. If | |
208 | the target of the link is a format which does not have many sections (eg | |
209 | @code{a.out}) or has sections without names (eg the Oasys format) the | |
210 | link cannot be done simply. You can circumvent this problem by | |
211 | describing the desired input-to-output section mapping with the linker command | |
212 | language. | |
213 | ||
214 | @emph{Information can be lost during canonicalization.} The BFD | |
215 | internal canonical form of the external formats is not exhaustive; there | |
216 | are structures in input formats for which there is no direct | |
217 | representation internally. This means that the BFD back ends | |
218 | cannot maintain all possible data richness through the transformation | |
219 | between external to internal and back to external formats. | |
220 | ||
221 | This limitation is only a problem when an application reads one | |
222 | format and writes another. Each BFD back end is responsible for | |
223 | maintaining as much data as possible, and the internal BFD | |
224 | canonical form has structures which are opaque to the BFD core, | |
225 | and exported only to the back ends. When a file is read in one format, | |
226 | the canonical form is generated for BFD and the application. At the | |
227 | same time, the back end saves away any information which may otherwise | |
228 | be lost. If the data is then written back in the same format, the back | |
229 | end routine will be able to use the canonical form provided by the | |
230 | BFD core as well as the information it prepared earlier. Since | |
231 | there is a great deal of commonality between back ends, this mechanism | |
232 | is very useful. There is no information lost for this reason when | |
233 | linking or copying big endian COFF to little endian COFF, or @code{a.out} to | |
234 | @code{b.out}. When a mixture of formats is linked, the information is | |
235 | only lost from the files whose format differs from the destination. | |
236 | ||
a9773c89 | 237 | @node Mechanism, , BFD information loss, What BFD Version 1 Can Do |
80d29884 SC |
238 | @subsection Mechanism |
239 | The greatest potential for loss of information is when there is least | |
240 | overlap between the information provided by the source format, that | |
241 | stored by the canonical format, and the information needed by the | |
242 | destination format. A brief description of the canonical form may help | |
243 | you appreciate what kinds of data you can count on preserving across | |
244 | conversions. | |
245 | @cindex BFD canonical format | |
246 | @cindex internal object-file format | |
247 | ||
248 | @table @emph | |
249 | @item files | |
250 | Information on target machine architecture, particular implementation | |
251 | and format type are stored on a per-file basis. Other information | |
252 | includes a demand pageable bit and a write protected bit. Note that | |
253 | information like Unix magic numbers is not stored here---only the magic | |
254 | numbers' meaning, so a @code{ZMAGIC} file would have both the demand | |
255 | pageable bit and the write protected text bit set. The byte order of | |
256 | the target is stored on a per-file basis, so that big- and little-endian | |
257 | object files may be linked with one another. | |
258 | @c FIXME: generalize above from "link"? | |
259 | ||
260 | @item sections | |
261 | Each section in the input file contains the name of the section, the | |
262 | original address in the object file, various flags, size and alignment | |
263 | information and pointers into other BFD data structures. | |
264 | ||
265 | @item symbols | |
266 | Each symbol contains a pointer to the object file which originally | |
267 | defined it, its name, its value, and various flag bits. When a | |
268 | BFD back end reads in a symbol table, the back end relocates all | |
269 | symbols to make them relative to the base of the section where they were | |
270 | defined. This ensures that each symbol points to its containing | |
271 | section. Each symbol also has a varying amount of hidden data to contain | |
272 | private data for the BFD back end. Since the symbol points to the | |
273 | original file, the private data format for that symbol is accessible. | |
274 | @code{gld} can operate on a collection of symbols of wildly different | |
275 | formats without problems. | |
276 | ||
277 | Normal global and simple local symbols are maintained on output, so an | |
278 | output file (no matter its format) will retain symbols pointing to | |
279 | functions and to global, static, and common variables. Some symbol | |
280 | information is not worth retaining; in @code{a.out} type information is | |
281 | stored in the symbol table as long symbol names. This information would | |
282 | be useless to most COFF debuggers; the linker has command line switches | |
283 | to allow users to throw it away. | |
284 | ||
285 | There is one word of type information within the symbol, so if the | |
286 | format supports symbol type information within symbols (for example COFF, | |
287 | IEEE, Oasys) and the type is simple enough to fit within one word | |
288 | (nearly everything but aggregates) the information will be preserved. | |
289 | ||
290 | @item relocation level | |
291 | Each canonical BFD relocation record contains a pointer to the symbol to | |
292 | relocate to, the offset of the data to relocate, the section the data | |
293 | is in and a pointer to a relocation type descriptor. Relocation is | |
294 | performed effectively by message passing through the relocation type | |
295 | descriptor and symbol pointer. It allows relocations to be performed | |
296 | on output data using a relocation method only available in one of the | |
297 | input formats. For instance, Oasys provides a byte relocation format. | |
298 | A relocation record requesting this relocation type would point | |
299 | indirectly to a routine to perform this, so the relocation may be | |
300 | performed on a byte being written to a COFF file, even though 68k COFF | |
301 | has no such relocation type. | |
302 | ||
303 | @item line numbers | |
304 | Object formats can contain, for debugging purposes, some form of mapping | |
305 | between symbols, source line numbers, and addresses in the output file. | |
306 | These addresses have to be relocated along with the symbol information. | |
307 | Each symbol with an associated list of line number records points to the | |
308 | first record of the list. The head of a line number list consists of a | |
309 | pointer to the symbol, which allows divination of the address of the | |
310 | function whose line number is being described. The rest of the list is | |
311 | made up of pairs: offsets into the section and line numbers. Any format | |
312 | which can simply derive this information can pass it successfully | |
313 | between formats (COFF, IEEE and Oasys). | |
314 | @end table | |
315 | ||
316 | @c FIXME: what is this line about? Do we want introductory remarks | |
317 | @c FIXME... on back ends? commented out for now. | |
318 | @c What is a backend | |
a9773c89 RP |
319 | |
320 | ||
321 | @node BFD front end, BFD back end, Overview, Top | |
80d29884 SC |
322 | @chapter BFD front end |
323 | @include bfd.texi | |
324 | ||
a9773c89 RP |
325 | @menu |
326 | * Memory Usage:: | |
327 | * Initialization:: | |
328 | * Sections:: | |
329 | * Symbols:: | |
330 | * Archives:: | |
331 | * Formats:: | |
332 | * Relocations:: | |
333 | * Core Files:: | |
334 | * Targets:: | |
335 | * Architectures:: | |
336 | * Opening and Closing:: | |
337 | * Constructors:: | |
338 | * Internal:: | |
339 | * File Caching:: | |
340 | @end menu | |
341 | ||
342 | @node Memory Usage, Initialization, BFD front end, BFD front end | |
80d29884 SC |
343 | @section Memory Usage |
344 | BFD keeps all its internal structures in obstacks. There is one obstack | |
345 | per open BFD file, into which the current state is stored. When a BFD is | |
346 | closed, the obstack is deleted, and so everything which has been | |
347 | allocated by libbfd for the closing file will be thrown away. | |
348 | ||
349 | BFD will not free anything created by an application, but pointers into | |
350 | @code{bfd} structures will be invalidated on a @code{bfd_close}; for example, | |
351 | after a @code{bfd_close} the vector passed to | |
352 | @code{bfd_canonicalize_symtab} will still be around, since it has been | |
353 | allocated by the application, but the data that it pointed to will be | |
354 | lost. | |
355 | ||
356 | The general rule is not to close a BFD until all operations dependent | |
357 | upon data from the BFD have been completed, or all the data from within | |
358 | the file has been copied. To help with the management of memory, there is a function | |
359 | (@code{bfd_alloc_size}) which returns the number of bytes in obstacks | |
360 | associated with the supplied BFD. This could be used to select the | |
361 | greediest open BFD, close it to reclaim the memory, perform some | |
362 | operation and reopen the BFD again, to get a fresh copy of the data structures. | |
363 | ||
a9773c89 RP |
364 | @node Initialization, Sections, Memory Usage, BFD front end |
365 | @include init.texi | |
366 | ||
367 | @node Sections, Symbols, Initialization, BFD front end | |
80d29884 SC |
368 | @include section.texi |
369 | ||
a9773c89 | 370 | @node Symbols, Archives, Sections, BFD front end |
80d29884 SC |
371 | @include syms.texi |
372 | ||
a9773c89 | 373 | @node Archives, Formats, Symbols, BFD front end |
80d29884 SC |
374 | @include archive.texi |
375 | ||
a9773c89 | 376 | @node Formats, Relocations, Archives, BFD front end |
80d29884 SC |
377 | @include format.texi |
378 | ||
a9773c89 | 379 | @node Relocations, Core Files, Formats, BFD front end |
80d29884 SC |
380 | @include reloc.texi |
381 | ||
a9773c89 | 382 | @node Core Files, Targets, Relocations, BFD front end |
80d29884 SC |
383 | @include core.texi |
384 | ||
a9773c89 | 385 | @node Targets, Architectures, Core Files, BFD front end |
80d29884 SC |
386 | @include targets.texi |
387 | ||
a9773c89 | 388 | @node Architectures, Opening and Closing, Targets, BFD front end |
80d29884 SC |
389 | @include archures.texi |
390 | ||
a9773c89 | 391 | @node Opening and Closing, Constructors, Architectures, BFD front end |
80d29884 SC |
392 | @include opncls.texi |
393 | ||
a9773c89 RP |
394 | @node Constructors, Internal, Opening and Closing, BFD front end |
395 | @include ctor.texi | |
396 | ||
397 | @node Internal, File Caching, Constructors, BFD front end | |
80d29884 SC |
398 | @include libbfd.texi |
399 | ||
a9773c89 | 400 | @node File Caching, , Internal, BFD front end |
80d29884 SC |
401 | @include cache.texi |
402 | ||
a9773c89 | 403 | @node BFD back end, Index, BFD front end, Top |
80d29884 | 404 | @chapter BFD back end |
80d29884 | 405 | @menu |
a9773c89 RP |
406 | * What to put where:: |
407 | * aout :: a.out backends | |
408 | * coff :: coff backends | |
409 | @ignore | |
410 | * oasys :: oasys backends | |
411 | * ieee :: ieee backend | |
412 | * srecord :: s-record backend | |
413 | @end ignore | |
80d29884 | 414 | @end menu |
a9773c89 | 415 | @node What to Put Where, aout, BFD back end, BFD back end |
80d29884 SC |
416 | All of BFD lives in one directory. |
417 | ||
a9773c89 | 418 | @node aout, coff, What to Put Where, BFD back end |
80d29884 SC |
419 | @include aoutx.texi |
420 | ||
a9773c89 | 421 | @node coff, , aout, BFD back end |
80d29884 SC |
422 | @include coffcode.texi |
423 | ||
a9773c89 | 424 | @node Index, , BFD back end, Top |
80d29884 SC |
425 | @unnumbered Index |
426 | @printindex cp | |
427 | ||
428 | @tex | |
429 | % I think something like @colophon should be in texinfo. In the | |
430 | % meantime: | |
431 | \long\def\colophon{\hbox to0pt{}\vfill | |
432 | \centerline{The body of this manual is set in} | |
433 | \centerline{\fontname\tenrm,} | |
434 | \centerline{with headings in {\bf\fontname\tenbf}} | |
435 | \centerline{and examples in {\tt\fontname\tentt}.} | |
436 | \centerline{{\it\fontname\tenit\/} and} | |
437 | \centerline{{\sl\fontname\tensl\/}} | |
438 | \centerline{are used for emphasis.}\vfill} | |
439 | \page\colophon | |
440 | % Blame: pesch@cygnus.com, 28mar91. | |
441 | @end tex | |
442 | ||
80d29884 SC |
443 | @contents |
444 | @bye | |
445 | ||
446 |