This file documents the BFD library.

Copyright © 1991-2019 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with the Invariant Sections being ``GNU General Public License'' and ``Funding Free Software'', the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below).  A copy of the license is included in the section entitled ``GNU Free Documentation License''.

(a) The FSF's Front-Cover Text is:

A GNU Manual

(b) The FSF's Back-Cover Text is:

You have freedom to copy and modify this GNU Manual, like GNU software.  Copies published by the Free Software Foundation raise funds for GNU development.

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 successfully 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 (see Sections),

  * a set of relocations (see Relocations), and

  * some symbol information (see 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
=========================

     [file bfdsumm.texi not included]

BFD Front End
*************

     [file bfdt.texi not included]
     [file bfdio.texi not included]

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.

     [file init.texi not included]

     [file section.texi not included]

     [file syms.texi not included]

     [file archive.texi not included]

     [file format.texi not included]

     [file reloc.texi not included]

     [file core.texi not included]

     [file targets.texi not included]

     [file archures.texi not included]

     [file opncls.texi not included]

     [file libbfd.texi not included]

     [file cache.texi not included]

     [file linker.texi not included]

     [file hash.texi not included]

BFD back ends
*************

What to Put Where
=================

All of BFD lives in one directory.

     [file aoutx.texi not included]

     [file coffcode.texi not included]

     [file elf.texi not included]

     [file mmo.texi not included]

     [file fdl.texi not included]