
Binary File Descriptor library (a.k.a. BFD/libbfd) - peter_d_sherman
https://en.wikipedia.org/wiki/Binary_File_Descriptor_library
======
peter_d_sherman
Excerpt:

"BFD works by presenting a _common abstract view of object files_.

An object file has a "header" with descriptive info; a variable number of
"sections" that each has a name, some attributes, and a block of data; a
symbol table; relocation entries; and so forth.

Internally, BFD translates the data from the abstract view into the details of
the bit/byte layout required by the target processor and file format. Its key
services include handling byte order differences, such as between a little-
endian host and big-endian target, correct conversion between 32-bit and
64-bit data, and details of address arithmetic specified by relocation
entries.

Although BFD was originally designed to be a generic library usable by a wide
variety of tools, the frequent need to tinker with the API to accommodate new
systems' capabilities has tended to limit its use;[2][3][4] BFD's main clients
are the GNU Assembler (GAS), GNU Linker (GLD), and other GNU Binary Utilities
("binutils") tools, and the GNU Debugger (GDB). As a result, BFD is not
distributed separately, but is always included with releases of binutils and
GDB. Nevertheless, BFD is a critical component in the use of GNU tools for
embedded systems development.

The BFD library can be used to read the structured data out of a core dump."

Related: [https://ftp.gnu.org/old-
gnu/Manuals/bfd-2.9.1/html_chapter/b...](https://ftp.gnu.org/old-
gnu/Manuals/bfd-2.9.1/html_chapter/bfd_1.html)

Excerpt:

"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 b.out. There is nowhere in an a.out format file to store
alignment information on the contained data, so when a file is linked from
b.out and an 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., a.out) or has
sections without names (e.g., the Oasys format), the link cannot be done
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 formats 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."

Opinion:

The information loss aspect should be properly understood.

libbfd is trying to act as a "bridge" between all different object file
formats(!), all of which evolved differently.

Object files are no different than databases; to understand this in database
terms, think of a tool that's trying to unify all 'customer' or 'product'
databases...

There will be similarities, database to database (every 'customer' database
will have a customer name, every 'product' database will have a 'product'
name), but there will be additional pieces of data that show up in one, that
don't show up in the other... that's the information loss that we're talking
about.

libbfd, again, is trying to act as a "bridge" between these different
"databases"!

That makes libbfd quite the Software Engineering undertaking, despite this
"limitation"!

In my opinion, anyone who has to work with object file formats (e.g., compiler
writers and would-be compiler writers) should study this tool...

