\input texinfo
@setfilename bfdinfo
@c $Id$
-@synindex ky cp
+@syncodeindex fn cp
@ifinfo
This file documents the BFD library.
@end ifinfo
@iftex
@c@finalout
+@setchapternewpage on
@c@setchapternewpage odd
@settitle LIB BFD, the Binary File Descriptor Library
@titlepage
@title{libbfd}
@subtitle{The Binary File Descriptor Library}
@sp 1
-@subtitle First Edition---@code{bfd} version < 2.0
+@subtitle First Edition---BFD version < 2.0
@subtitle April 1991
@author {Steve Chamberlain}
@author {Cygnus Support}
@end ifinfo
@menu
-* Overview:: Overview of bfd
-* History:: History of bfd
+* Overview:: Overview of BFD
+* History:: History of BFD
* Backends:: Backends
* Porting:: Porting
* Future:: Future
* Internal::
* File Caching::
-Bfd backends:
+BFD backends:
* a.out backends::
* coff backends::
@end menu
@chapter Introduction
@cindex BFD
@cindex what is it?
-Simply put, @code{bfd} is a package which allow applications to use the
+BFD is a package for manipulating binary files required for developing
+programs. It implements a group of structured operations designed to
+shield the programmer from the underlying representation of these
+binary files. It understands object (compiled) files, archive
+libraries, and core files. It is designed to work in a variety of
+target environments.
+
+Most simply put, BFD is a package which allows applications to use the
same routines to operate on object files whatever the object file
-format. A different object file format can be supported simply by
-creating a new BFD back end and adding it to the library.
+format.
BFD is split into two parts; the front end and the many back ends.
@itemize @bullet
-@item The front end of bfd provides the interface to the user. It manages
+@item
+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.
-@item 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.
+@item
+The back ends provide BFD its view of the real world. A different
+object file format can be supported simply by creating a new BFD back
+end and adding it to the library. 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.
@end itemize
@node History, How It Works, Overview,Top
@section History
-One spur behind @code{bfd} was the Intel Oregon's GNU 960 team desire for
-interoperability of applications on their COFF and b.out file formats.
-Cygnus was providing GNU support for the team, and Cygnus were
-contracted to provid the required functionality.
+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
+Cygnus was contracted to provide the required functionality.
-The name came from a conversation Gumby Wallace was
-having with Richard Stallman about the library, RMS said that it
-would be quite hard, Gumby said BFD. (Stallman was right, but the name
-stuck).
+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.
+different object file formats: IEEE-695, Oasys, Srecords, a.out and 68k
+coff.
BFD was first implemented by Steve Chamberlain (steve@@cygnus.com),
John Gilmore (gnu@@cygnus.com), K. Richard Pixley (rich@@cygnus.com) and
-Gumby Wallace (gumby@@cygnus.com) at Cygnus Support in Palo Alto,
+David Wallace (gumby@@cygnus.com) at Cygnus Support in Palo Alto,
California.
@node How It Works, History, Porting, Top
To use the library, include @code{bfd.h} and link with @code{libbfd.a}.
-@code{bfd} provides a common interface to the parts of an object file
-to a calling application.
+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 @code{bfd}, described in
+@code{include/bfd.h}. Our convention is to call this pointer a BFD, and
+instances of it within code @code{abfd}. All operations on
+the target object file are applied as methods to the BFD. The mapping is
+defined within @code{bfd.h} in a set of macros, all beginning
+@samp{bfd_}.
+
+In short, a BFD is a representation for a particular file. It is opened
+in a manner similar to a file; code then manipulates it rather than the
+raw files.
-When an application sucessfully opens a
-target file (object, archive or whatever) a pointer to an internal
-structure is returned. This pointer points to structure described in
-@code{include/bfd.h}, called @code{bfd}. Conventionally this pointer is
-called a @code{bfd}, and instances of it within code are called
-@code{abfd}. All operations on the target object file are applied as
-methods to the @code{bfd}, the mapping is defined within @code{bfd.h} in
-a set of macros, all beginning @code{bfd}_something.
+For example, this sequence would do what you would probably expect:
+return the number of sections in an object file attached to a BFD
+@code{abfd}.
-For example, this sequence would do what you expect:
@lisp
@cartouche
#include "bfd.h"
@end cartouche
@end lisp
-The metaphor used within @code{bfd} is that an object file has a header,
+The abstraction used within BFD is that an object file has a header,
a number of sections containing raw data, a set of relocations, and some
-symbol information. Also, @code{bfd}s opened upon archives have the
-additional attribute of an index and contained sub bfds. This approach is
-find for a.out and coff, but looses efficiency when applied to formats
+symbol information. 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.
-@section What BFD Version 1 Can't Do
+@cindex targets
+@cindex formats
+BFD makes a distinction between @dfn{targets} (families of file
+formats) and @dfn{formats} (individual file formats). For instance,
+the @code{"sun4os4"} target can handle core, object and archive formats of
+files. The exact layout of the different formats depends on the target
+environment.
+
+The target @code{"default"} means the first one known (usually used for
+environments that only support one format, or where the common format
+is known at compile or link time). The target @code{NULL} means the one
+specified at runtime in the environment variable @code{GNUTARGET}; if that is
+null or not defined then, on output, the first entry in the target list
+is chosen; or, on input, all targets are searched to find a matching
+one.
+
+Most programs should use the target @code{NULL}. See the descriptions
+of @code{bfd_target_list} and @code{bfd_format_string} for functions to
+inquire on targets and formats.
+
+@section What BFD Version 1 Can Do
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
canonical format. When the linker asks for the symbol table of an object
file, it calls through the memory pointer to the relevant BFD
back end routine which reads and converts the table into a canonical
-form. The linker then operates upon the common form. When the link is
-finished and the linker writes the symbol table of the output file,
+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 which takes the newly
created symbol table and converts it into the chosen output format.
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 using the linker to read one
- format and write another. Each BFD back end is responsible for
+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 linker. At the
+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, this mechanism
is very useful. There is no information lost for this reason when
-linking big endian COFF to little endian COFF, or from @code{a.out} to
+linking or copying big endian COFF to little endian COFF, or @code{a.out} to
@code{b.out}. When a mixture of formats is linked, the information is
only lost from the files whose format differs from the destination.
and format type are stored on a per-file basis. Other information
includes a demand pageable bit and a write protected bit. Note that
information like Unix magic numbers is not stored here---only the magic
-numbers' meaning, so a @code{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 linked with one another.
+numbers' meaning, so a @code{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 linked with one another.
+@c FIXME: generalize above from "link"?
@item sections
Each section in the input file contains the name of the section, the
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 @code{a.out} type information is
-stored in the symbol table as long symbol names. This information would
-be useless to most COFF debuggers and may be thrown away with
-appropriate command line switches. (The GNU debugger @code{gdb} does
-support @code{a.out} style debugging information in COFF).
+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,
between formats (COFF, IEEE and Oasys).
@end table
-
-What is a backend
+@c FIXME: what is this line about? Do we want introductory remarks
+@c FIXME... on back ends? commented out for now.
+@c What is a backend
@node BFD front end, BFD back end, Mechanism, Top
-@page
@chapter BFD front end
-@include bfd.c.texi
-@page
-@node Memory Usage, Sections, bfd, Top
+@include bfd.texi
+
+@node Memory Usage, Errors, bfd, Top
@section Memory Usage
BFD keeps all its internal structures in obstacks. There is one obstack
-per open bfd file, into which the current state is stored. When a bfd is
+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 libbfd for the closing file will be thrown away.
BFD will not free anything created by an application, but pointers into
-bfd structures will be invalidated on a @code{bfd_close}; for example,
+@code{bfd} structures will be invalidated on a @code{bfd_close}; for example,
after a @code{bfd_close} the vector passed to
@code{bfd_canonicalize_symtab} will still be around, since it has been
allocated by the application, but the data that it pointed to will be
lost.
-The general rule is not to close a bfd until all operations dependent
-upon data from the bfd have been completed, or all the data from within
+The general rule is not to 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
(@code{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.
-
-@node Sections,Symbols ,Memory Usage, Top
+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.
+
+@node Errors, Sections, Memory Usage, Top
+@section Error Handling
+
+@cindex errors
+In general, a boolean function returns true on success and false on failure
+(unless it's a predicate). Functions which return pointers to
+objects return @code{NULL} on error. The specifics are documented with each
+function.
+
+If a function fails, you should check the variable @code{bfd_error}. If
+the value is @code{no_error}, then check the C variable @code{errno}
+just as you would with any other program. Other values for
+@code{bfd_error} are documented in @file{bfd.h}.
+
+@findex bfd_errmsg
+If you would prefer a comprehensible string for the error message, use
+the function @code{bfd_errmsg}:
+@example
+char * bfd_errmsg (error_tag)
+@end example
+This function returns a read-only string which documents the error
+code. If the error code is @code{no_error} then it will return a string
+depending on the value of @code{errno}.
+
+@findex bfd_perror
+@code{bfd_perror()} is like the @code{perror()} function except it understands
+@code{bfd_error}.
+
+
+@node Sections, Symbols, Errors, Top
@include section.texi
-@page
+
@node Symbols, Archives ,Sections, To
@include syms.texi
-@page
+
@node Archives, Formats, Symbols, Top
@include archive.texi
-@page
+
@node Formats, Relocations, Archives, Top
@include format.texi
-@page
+
@node Relocations, Core Files,Formats, Top
@include reloc.texi
-@page
+
@node Core Files, Targets, Relocations, Top
@include core.texi
-@page
+
@node Targets, Architectures, Core Files, Top
@include targets.texi
-@page
+
@node Architectures, Opening and Closing, Targets, Top
@include archures.texi
-@page
+
@node Opening and Closing, Internal, Architectures, Top
@include opncls.texi
-@page
+
@node Internal, File Caching, Opening and Closing, Top
@include libbfd.texi
-@page
+
@node File Caching, Top, Internal, Top
@include cache.texi
-@page
+
@chapter BFD back end
@node BFD back end, ,BFD front end, Top
@menu
* srecord backend::
@end menu
@node What to Put Where, aout backends, BFD back end, BFD back end
-All of bfd lives in one directory.
-@page
+All of BFD lives in one directory.
+
@node aout backends, coff backends, What to Put Where, BFD back end
-@include aoutx.h.texi
-@page
+@include aoutx.texi
+
@node coff backends, oasys backends, aout backends, BFD back end
-@include coffcode.h.texi
-@page
+@include coffcode.texi
+
@node Index, , BFD, Top
-@unnumbered Function Index
-@printindex fn
-@setchapternewpage on
@unnumbered Index
@printindex cp
projects / deliverable / binutils-gdb.git / blobdiff