4 ms·

Binary File Descriptor library (a.k.a. BFD/libbfd)

peter_d_sherman 7y ago
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/bfd_1.html https://ftp.gnu.org/old-gnu/Manuals/bfd-2.9.1/html_chapter/b... 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...

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/bfd_1.html https://ftp.gnu.org/old-gnu/Manuals/bfd-2.9.1/html_chapter/b... 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...