二进制文件格式

要理解为什么 FreeBSD 使用
elf(5)
格式，
您必须首先了解一些 UNIX® 系统中的 三种 “主要”
可执行文件格式的有关知识：

• 
  a.out(5)
  是最古老和“经典的” UNIX 目标文件格式，
  这种格式在其文件的开始处有一个短小而又紧凑的首部，
  该首部带有一个魔幻数字，用来标识具体的格式(更多详情参见
  a.out(5)
  )。
  这种格式包含3个要装载入内存的段：.text， .data， 和 .bss，以及
  一个符号表和一个字符串表。
  
• 
  COFF
  SVR3目标文件格式。其文件头现在包括一个区段表(section table)，
  因此除了.text，.data，和.bss区段以外，您还可以包含其它的区段。
  
• 
  elf(5)
  COFF 的后继， 其特点是可以有多个区段，
  并可以使用32位或64位的值。 它有一个主要的缺点： ELF
  在其设计时假设每个系统体系结构只有一种 ABI。 这种假设事实上相当错误，
  甚至在商业化的SYSV世界中都是错误的 (它们至少有三种ABI: SVR4, Solaris, SCO)。
  FreeBSD试图在某种程度上解决这个问题，它提供一个工具，可以 对一个已知的ELF可执行文件 标识它所遵从的ABI的信息。 更多这方面的知识可以参见手册页
  brandelf(1)
  

　　FreeBSD从“经典”阵营中来，因此使用了
a.out(5)
格式，
众多BSD版本的发行(直到3.X分支的开始)也证明了这种格式的有效性。
虽然在那以前的某段时间，在FreeBSD系统上创建和运行ELF格式
的二进制可执行文件(和内核)也是可能的，但FreeBSD一开始并不积极“进步” 到使用ELF作为其缺省的格式。为什么？噢，当Linux阵营完成了
转换到ELF格式的痛苦历程后，却发现并不足以由此而放弃
a.out可执行文件格式，因为正是由于它们不灵活的，
基于跳转表的共享库机制，使得销售商和开发者们构建共享库非常困难。 直到已有的ELF工具提供了一种解决共享库问题的办法，
并被普遍认为是“前进方向”以后，迁徙的代价在FreeBSD界才被接受，
并由此完成了迁徙。FreeBSD的共享库机制其基础更类似于Sun SunOS™的共享库机制， 并且正因为此，其易用性很好。
　　那么，为什么会有这么多不同的格式呢？
　　回溯到蒙昧和黑暗的过去，那时只有简单的硬件。这种简单的硬件支撑了一个简单
和小型的系统。在这样的简单系统上(PDP-11)a.out格式
足以胜任表达二进制文件的任务。当人们将UNIX从这种简单的系统中移植出来的时候， a.out格式被保留了下来，因为对于早期将UNIX移植到 Motorola 68k，VAXen等系统来说，它还是足够可用的。
　　然后，一些聪明的硬件工程师认为，如果可以让软件完成一些简单的聪明操作，
那么他们就可以在硬件设计中减少若干门电路，并可以让CPU核心运行得更快。 当a.out格式用于这种新型的硬件系统时(现在我们叫它 RISC)，显得并不合适。因此，人们设计了许多新的格式
以便在这样的硬件系统上能获得比简单的a.out格式更优越
的性能。诸如COFF，ECOFF，还有其它
一些晦涩难懂的格式正是在这个阶段被发明出来的，人们也研究了这些格式的局限性，
慢慢地最终落实到ELF格式。
　　同时，程序的大小变得越来越大，磁盘空间(以及物理内存)相对来说却仍然较小，
因此共享库的概念便产生了。VM系统也变得越来越复杂了。当所有这些进步都建立在 a.out格式的基础上的时候，它的可用性随着每个新特性
的产生就受到了严重考验。并且，人们还希望可以在运行时动态装载某些东西，或者
在初始化代码运行以后可以丢弃部分程序代码，以便节约主存储器和交换区。编程语言

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有