Bfd; How It Works: An Outline Of Bfd; Information Loss - Red Hat ENTERPRISE LINUX 3 - USING ID Using Instructions

Chapter 6.

BFD

The linker accesses object and archive files using the BFD libraries. These libraries allow the linker
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. To
conserve runtime memory, however, the linker and associated tools are usually configured to support
only a subset of the object file formats available. You can use () to list all the formats
objdump -i
available for your configuration.
As with most implementations, BFD is a compromise between several conflicting requirements. The
major factor influencing BFD design was efficiency: any time used converting between formats is time
which would not have been spent had BFD not been involved. This is partly offset by abstraction pay-
back; since BFD simplifies applications and back ends, more time and care may be spent optimizing
algorithms for a greater speed.
One minor artifact of the BFD solution which you should bear in mind is the potential for information
loss. There are two places where useful information can be lost using the BFD mechanism: during
conversion and during output. Refer to Section 6.1.1 Information Loss.

6.1. How It Works: An Outline of BFD

When an object file is opened, BFD subroutines automatically determine the format of the input
object file. They then build a descriptor in memory with pointers to routines that will be used to
access elements of the object file's data structures.
As different information from 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
tables. Each BFD back end provides a routine for converting between the object file's representation
of symbols and an internal canonical format. When the linker asks for the symbol table of an object
file, it calls through a memory pointer to the routine from the relevant BFD back end which reads and
converts the table into a canonical 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 to take the newly created symbol table and convert it into the chosen output format.

6.1.1. Information Loss

Information can be lost during output. The output formats supported by BFD do not provide identical
facilities, and information which can be described in one form has nowhere to go in another format.
One example of this is alignment information in . There is nowhere in an format file to
b.out a.out
store alignment information on the contained data, so when a file is linked from and an
b.out a.out
image is produced, alignment information will not propagate to the output file. (The linker will still
use the alignment information internally, so the link is performed correctly).
Another example is COFF section names. COFF files may contain an unlimited number of sections,
each one with a textual section name. If the target of the link is a format which does not have many
sections (e.g., ) or has sections without names (e.g., the Oasys format), the link cannot be done
a.out
simply. You can circumvent this problem by describing the desired input-to-output section mapping
with the linker command language.
Information can be lost during canonicalization. The BFD internal canonical form of the external for-
mats is not exhaustive; there are structures in input formats for which there is no direct representation
internally. This means that the BFD back ends cannot maintain all possible data richness through the
transformation between external to internal and back to external formats.