LIB BFD, the Binary File Descriptor Library

Introduction

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: History
• How It Works: How It Works
• What BFD Version 2 Can Do: What BFD Version 2 Can Do

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 sucessfully 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 (@xref{Sections}),
• a set of relocations (@xref{Relocations}), and
• some symbol information (@xref{Symbols}).

What BFD Version 2 Can Do

BFD front end

• Memory Usage

Memory usage

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.

BFD back ends

Index