📄 binary-formats.html
字号:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta name="generator" content="HTML Tidy, see www.w3.org" /><title>Binary Formats</title><meta name="GENERATOR" content="Modular DocBook HTML Stylesheet Version 1.7" /><link rel="HOME" title="FreeBSD 使用手册" href="index.html" /><link rel="UP" title="UNIX Basics" href="basics.html" /><link rel="PREVIOUS" title="Devices and Device Nodes" href="basics-devices.html" /><link rel="NEXT" title="For More Information" href="basics-more-information.html" /><link rel="STYLESHEET" type="text/css" href="docbook.css" /><meta http-equiv="Content-Type" content="text/html; charset=GB2312" /></head><body class="SECT1" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#840084"alink="#0000FF"><div class="NAVHEADER"><table summary="Header navigation table" width="100%" border="0" cellpadding="0"cellspacing="0"><tr><th colspan="3" align="center">FreeBSD 使用手册</th></tr><tr><td width="10%" align="left" valign="bottom"><a href="basics-devices.html"accesskey="P">Prev</a></td><td width="80%" align="center" valign="bottom">Chapter 3. UNIX Basics</td><td width="10%" align="right" valign="bottom"><a href="basics-more-information.html"accesskey="N">Next</a></td></tr></table><hr align="LEFT" width="100%" /></div><div class="SECT1"><h1 class="SECT1"><a id="BINARY-FORMATS" name="BINARY-FORMATS">3.12. BinaryFormats</a></h1><p>To understand why FreeBSD uses the <acronym class="ACRONYM">ELF</acronym> format, youmust first know a little about the three currently ``dominant'' executable formats for<span class="TRADEMARK">UNIX</span>®:</p><ul><li><p><span class="CITEREFENTRY"><span class="REFENTRYTITLE">a.out</span>(5)</span></p><p>The oldest and ``classic'' <span class="TRADEMARK">UNIX</span> object format. It usesa short and compact header with a magic number at the beginning that is often used tocharacterize the format (see <span class="CITEREFENTRY"><spanclass="REFENTRYTITLE">a.out</span>(5)</span> for more details). It contains three loadedsegments: .text, .data, and .bss plus a symbol table and a string table.</p></li><li><p><acronym class="ACRONYM">COFF</acronym></p><p>The SVR3 object format. The header now comprises a section table, so you can have morethan just .text, .data, and .bss sections.</p></li><li><p><acronym class="ACRONYM">ELF</acronym></p><p>The successor to <acronym class="ACRONYM">COFF</acronym>, featuring multiple sectionsand 32-bit or 64-bit possible values. One major drawback: <acronymclass="ACRONYM">ELF</acronym> was also designed with the assumption that there would beonly one ABI per system architecture. That assumption is actually quite incorrect, andnot even in the commercial SYSV world (which has at least three ABIs: SVR4, Solaris, SCO)does it hold true.</p><p>FreeBSD tries to work around this problem somewhat by providing a utility for <spanclass="emphasis"><i class="EMPHASIS">branding</i></span> a known <acronymclass="ACRONYM">ELF</acronym> executable with information about the ABI it is compliantwith. See the manual page for <span class="CITEREFENTRY"><spanclass="REFENTRYTITLE">brandelf</span>(1)</span> for more information.</p></li></ul><p>FreeBSD comes from the ``classic'' camp and used the <span class="CITEREFENTRY"><spanclass="REFENTRYTITLE">a.out</span>(5)</span> format, a technology tried and proventhrough many generations of BSD releases, until the beginning of the 3.X branch. Thoughit was possible to build and run native <acronym class="ACRONYM">ELF</acronym> binaries(and kernels) on a FreeBSD system for some time before that, FreeBSD initially resistedthe ``push'' to switch to <acronym class="ACRONYM">ELF</acronym> as the default format.Why? Well, when the Linux camp made their painful transition to <acronymclass="ACRONYM">ELF</acronym>, it was not so much to flee the <ttclass="FILENAME">a.out</tt> executable format as it was their inflexible jump-table basedshared library mechanism, which made the construction of shared libraries very difficultfor vendors and developers alike. Since the <acronym class="ACRONYM">ELF</acronym> toolsavailable offered a solution to the shared library problem and were generally seen as``the way forward'' anyway, the migration cost was accepted as necessary and thetransition made. FreeBSD's shared library mechanism is based more closely on Sun's <spanclass="TRADEMARK">SunOS</span>™ style shared library mechanism and, as such, isvery easy to use.</p><p>So, why are there so many different formats?</p><p>Back in the dim, dark past, there was simple hardware. This simple hardware supporteda simple, small system. <tt class="FILENAME">a.out</tt> was completely adequate for thejob of representing binaries on this simple system (a PDP-11). As people ported <spanclass="TRADEMARK">UNIX</span> from this simple system, they retained the <ttclass="FILENAME">a.out</tt> format because it was sufficient for the early ports of <spanclass="TRADEMARK">UNIX</span> to architectures like the Motorola 68k, VAXen, etc.</p><p>Then some bright hardware engineer decided that if he could force software to do somesleazy tricks, then he would be able to shave a few gates off the design and allow hisCPU core to run faster. While it was made to work with this new kind of hardware (knownthese days as <acronym class="ACRONYM">RISC</acronym>), <tt class="FILENAME">a.out</tt>was ill-suited for this hardware, so many formats were developed to get to a betterperformance from this hardware than the limited, simple <tt class="FILENAME">a.out</tt>format could offer. Things like <acronym class="ACRONYM">COFF</acronym>, <acronymclass="ACRONYM">ECOFF</acronym>, and a few obscure others were invented and theirlimitations explored before things seemed to settle on <acronymclass="ACRONYM">ELF</acronym>.</p><p>In addition, program sizes were getting huge and disks (and physical memory) werestill relatively small so the concept of a shared library was born. The VM system alsobecame more sophisticated. While each one of these advancements was done using the <ttclass="FILENAME">a.out</tt> format, its usefulness was stretched more and more with eachnew feature. In addition, people wanted to dynamically load things at run time, or tojunk parts of their program after the init code had run to save in core memory and swapspace. Languages became more sophisticated and people wanted code called before mainautomatically. Lots of hacks were done to the <tt class="FILENAME">a.out</tt> format toallow all of these things to happen, and they basically worked for a time. In time, <ttclass="FILENAME">a.out</tt> was not up to handling all these problems without an everincreasing overhead in code and complexity. While <acronym class="ACRONYM">ELF</acronym>solved many of these problems, it would be painful to switch from the system thatbasically worked. So <acronym class="ACRONYM">ELF</acronym> had to wait until it was morepainful to remain with <tt class="FILENAME">a.out</tt> than it was to migrate to <acronymclass="ACRONYM">ELF</acronym>.</p><p>However, as time passed, the build tools that FreeBSD derived their build tools from(the assembler and loader especially) evolved in two parallel trees. The FreeBSD treeadded shared libraries and fixed some bugs. The GNU folks that originally write theseprograms rewrote them and added simpler support for building cross compilers, plugging indifferent formats at will, and so on. Since many people wanted to build cross compilerstargeting FreeBSD, they were out of luck since the older sources that FreeBSD had for <bclass="APPLICATION">as</b> and <b class="APPLICATION">ld</b> were not up to the task. Thenew GNU tools chain (<b class="APPLICATION">binutils</b>) does support cross compiling,<acronym class="ACRONYM">ELF</acronym>, shared libraries, C++ extensions, etc. Inaddition, many vendors are releasing <acronym class="ACRONYM">ELF</acronym> binaries, andit is a good thing for FreeBSD to run them.</p><p><acronym class="ACRONYM">ELF</acronym> is more expressive than <ttclass="FILENAME">a.out</tt> and allows more extensibility in the base system. The<acronym class="ACRONYM">ELF</acronym> tools are better maintained, and offer crosscompilation support, which is important to many people. <acronymclass="ACRONYM">ELF</acronym> may be a little slower than <ttclass="FILENAME">a.out</tt>, but trying to measure it can be difficult. There are alsonumerous details that are different between the two in how they map pages, handle initcode, etc. None of these are very important, but they are differences. In time supportfor <tt class="FILENAME">a.out</tt> will be moved out of the <ttclass="FILENAME">GENERIC</tt> kernel, and eventually removed from the kernel once theneed to run legacy <tt class="FILENAME">a.out</tt> programs is past.</p></div><div class="NAVFOOTER"><hr align="LEFT" width="100%" /><table summary="Footer navigation table" width="100%" border="0" cellpadding="0"cellspacing="0"><tr><td width="33%" align="left" valign="top"><a href="basics-devices.html"accesskey="P">Prev</a></td><td width="34%" align="center" valign="top"><a href="index.html"accesskey="H">Home</a></td><td width="33%" align="right" valign="top"><a href="basics-more-information.html"accesskey="N">Next</a></td></tr><tr><td width="33%" align="left" valign="top">Devices and Device Nodes</td><td width="34%" align="center" valign="top"><a href="basics.html"accesskey="U">Up</a></td><td width="33%" align="right" valign="top">For More Information</td></tr></table></div></body></html>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -