BFD文件描述格式：前端与后端详解

需积分: 25 16 浏览量更新于2024-08-02 收藏 636KB PDF 举报

BFD (Binary File Descriptor) 是一个重要的软件库，它在 IT 领域中的作用是提供一种标准化的方法来处理不同类型的二进制对象文件，无论其具体格式如何。该库由 Steve Chamberlain 开发，最初版本发布于 April 1991 年，隶属于 Cygnus Support，并且自那时起持续更新和完善。BFD 的设计分为前端和后端两部分：前端是用户接口，它管理内存和维护各种通用的数据结构，如重定位表和段描述符等；而后端则是针对每种特定对象文件格式（如ELF、COFF、a.out等）的实现，它们负责解析和操作这些文件的底层细节。当需要支持新的对象文件格式时，开发者只需创建一个新的 BFD 后端并将其添加到库中，这样就能确保应用程序在处理不同格式的文件时都能保持一致性。BFD 的这种模块化设计极大地提高了代码的可复用性和灵活性，使得软件开发者能够专注于他们关心的特定功能，而无需关心底层文件格式的具体细节。 BFD 提供了一套强大的API，允许用户进行诸如加载、解析、修改和链接等操作。它支持的功能包括但不限于： 1. **兼容性处理**：BFD 允许开发人员编写跨平台的工具和程序，因为它们可以共享相同的接口来处理不同的对象文件格式。 2. **错误检测与处理**：通过统一的错误处理机制，BFD 可以帮助开发者更容易地诊断和解决与文件格式相关的错误。 3. **调试支持**：BFD 的反汇编器和调试功能使得调试器能跨越不同架构的二进制代码，增强了调试工具的普遍适用性。 4. **动态链接**：BFD 有助于实现动态链接器，它能够在运行时识别和连接目标程序依赖的动态库。 BFD 版本 1.3 及后续更新，如 1999-09-25.10 版本，不仅提供了功能的增强，还遵循了 GNU Free Documentation License，这意味着它的文档是自由可复制、分发和修改的，鼓励开源社区的贡献和学习。总结来说，BFD 文件描述格式库是一个基石般的技术，对于软件开发特别是构建跨平台工具和系统具有深远的影响，它的核心价值在于提供了一种标准方法来处理多样化的二进制文件格式，促进了代码的移植性和可维护性。

Chapter 2: BFD front end 14

Description

Set private BFD ﬂag information in the BFD abfd. Return true on success, false on error.

Possible error returns are:

• bfd_error_no_memory - Not enough memory exists to create private data for obfd.

#define bfd_set_private_flags(abfd, flags) \

BFD_SEND (abfd, _bfd_set_private_flags, \

(abfd, flags))

2.3.0.16 stuff

Description

Stuﬀ which should be documented:

#define bfd_sizeof_headers(abfd, reloc) \

BFD_SEND (abfd, _bfd_sizeof_headers, (abfd, reloc))

#define bfd_find_nearest_line(abfd, sec, syms, off, file, func, line) \

BFD_SEND (abfd, _bfd_find_nearest_line, (abfd, sec, syms, off, file, func, line))

/* Do these three do anything useful at all, for any back end? */

#define bfd_debug_info_start(abfd) \

BFD_SEND (abfd, _bfd_debug_info_start, (abfd))

#define bfd_debug_info_end(abfd) \

BFD_SEND (abfd, _bfd_debug_info_end, (abfd))

#define bfd_debug_info_accumulate(abfd, section) \

BFD_SEND (abfd, _bfd_debug_info_accumulate, (abfd, section))

#define bfd_stat_arch_elt(abfd, stat) \

BFD_SEND (abfd, _bfd_stat_arch_elt,(abfd, stat))

#define bfd_update_armap_timestamp(abfd) \

BFD_SEND (abfd, _bfd_update_armap_timestamp, (abfd))

#define bfd_set_arch_mach(abfd, arch, mach)\

BFD_SEND ( abfd, _bfd_set_arch_mach, (abfd, arch, mach))

#define bfd_relax_section(abfd, section, link_info, again) \

BFD_SEND (abfd, _bfd_relax_section, (abfd, section, link_info, again))

#define bfd_gc_sections(abfd, link_info) \

BFD_SEND (abfd, _bfd_gc_sections, (abfd, link_info))

#define bfd_merge_sections(abfd, link_info) \

BFD_SEND (abfd, _bfd_merge_sections, (abfd, link_info))

#define bfd_link_hash_table_create(abfd) \

BFD_SEND (abfd, _bfd_link_hash_table_create, (abfd))

Chapter 2: BFD front end 16

The general rule is to not c lose a BFD until all operations dependent upon data from the

BFD have been completed, or all the data from within the ﬁle 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.

2.5 Initialization

These are the functions that handle initializing a BFD.

2.5.0.1 bfd_init

Synopsis

void bfd_init(void);

Description

This routine must be called be fore any other BFD function to initialize magic al internal

data structures.

2.6 Sections

The raw data contained within a BFD is maintained through the section abstraction. A

single BFD may have any number of sections. It keeps hold of them by pointing to the ﬁrst;

each one points to the next in the list.

Sections are supported in BFD in section.c.

2.6.1 Section input

When a BFD is opened for reading, the section structures are c reated and attached to the

BFD.

Each se ction has a name which describes the section in the outside world—for example,

a.out would contain at least three sections, called .text, .data and .bss.

Names need not be unique; for example a COFF ﬁle may have several sections named .data.

Sometimes a BFD will contain more than the “natural” number of sections. A back end

may attach other sections containing constructor data, or an application may add a section

(using bfd_make_section) to the sections attached to an already open BFD. For example,

the linker creates an extra se ction COMMON for each input ﬁle’s BFD to hold information

about common storage.

The raw data is not necessarily read in when the section descriptor is created. Some targets

may leave the data in place until a bfd_get_section_contents call is made. Other back

ends may read in all the data at once. For example, an S-record ﬁle has to be read once to

determine the size of the data. An IEEE-695 ﬁle doesn’t contain raw data in sections, but

data and relocation expressions intermixed, so the data area has to be parsed to get out

the data and relocations.

Chapter 2: BFD front end 17

2.6.2 Section output

To write a new object style BFD, the various sections to be written have to be c reated.

They are attached to the BFD in the same way as input sections; data is written to the

sections using bfd_set_section_contents.

Any program that creates or combines sections (e.g., the assembler and linker) must use the

asection ﬁelds output_section and output_offset to indicate the ﬁle sections to which

each section must be written. (If the section is being created from scratch, output_section

should probably p oint to the section itself and output_offset should probably be zero.)

The data to be written comes from input sections attached (via output_section pointers)

to the output sections. The output section structure can be considered a ﬁlter for the input

section: the output section determines the vma of the output data and the name, but the

input section determines the oﬀset into the output section of the data to be written.

E.g., to create a section "O", starting at 0x100, 0x123 long, containing two subsections, "A"

at oﬀset 0x0 (i.e., at vma 0x100) and "B" at oﬀset 0x20 (i.e., at vma 0x120) the asection

structures would look like:

section name "A"

output_offset 0x00

size 0x20

output_section -----------> section name "O"

| vma 0x100

section name "B" | size 0x123

output_offset 0x20 |

size 0x103 |

output_section --------|

2.6.3 Link orders

The data within a section is stored in a link order. These are much like the ﬁxups in gas.

The link order abstraction allows a section to grow and shrink within itself.

A link order knows how big it is, and which is the next link order and where the raw data

for it is; it also p oints to a list of relocations which apply to it.

The link order is used by the linker to perform relaxing on ﬁnal code. The compiler creates

code which is as big as necessary to make it work without relaxing, and the user can select

whether to relax. Sometimes relaxing takes a lot of time. The linker runs around the

relocations to see if any are attached to data which can be shrunk, if so it does it on a

link order by link order basis.

2.6.4 typedef asection

Here is the section structure:

/* This structure is used for a comdat section, as in PE. A comdat

section is associated with a particular symbol. When the linker

sees a comdat section, it keeps only one of the sections with a

given name and associated with a given symbol. */

剩余137页未读，继续阅读

Bandit_007

粉丝: 0
资源: 4

BFD文件描述格式：前端与后端详解

SPU ELF支持与BFD集成的技术细节

BFD联动静态配置与分析

Go语言库go-bfd：实现IPv4/IPv6单跳BFD协议

华为数通bfd.rar

bfd.rar_The Main

基于BFD算法的SOC测试环优化

6cc7ecca3035aba5bfd52683f971faf1:应用程式编号5462

bfd6ba8c-9fc2-4970-a04d-ef38fe9e2428:咖喱角

Inkscape插件教程：如何使用BFD斐波那契模式生成器

Save-PS-to-SVG2.0.jsx脚本：将PS文件转换为SVG格式

最新资源