os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Remove the binary format section of Traditoinal Chinese handbook

Browse source 
chapter 3 Unix basics.  This was removed from the English version
in r42604 in 2013,

Submitted by:	RayCherng Yu <raycherng@gmail.com>
Approved by:	wblock
Differential Revision:	https://reviews.freebsd.org/D4081
This commit is contained in:
Li-Wen Hsu 2015-11-07 18:19:27 +00:00
parent 4766f73174
commit e16d263ec9
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=47756
1 changed files with 0 additions and 140 deletions
Download patch file Download diff file Expand all files Collapse all files

140
zh_TW.UTF-8/books/handbook/basics/chapter.xml
View file

@ -2925,146 +2925,6 @@ Swap: 256M Total, 38M Used, 217M Free, 15% Inuse
</sect2>
</sect1>
<sect1 xml:id="binary-formats">
<title>Binary 的格式</title>
<para>若要知道為何 &os; 是採用 &man.elf.5; 格式，必先瞭解當前 &unix;
系統中三種<quote>影響最為重大</quote>的可執行檔相關背景：</para>
<itemizedlist>
<listitem>
<para>&man.a.out.5;</para>
<para>最古老、<quote>經典</quote> 的 &unix; object 檔格式。
It uses a short and compact header with a magic
number at the beginning that is often used to characterize
the format (see &man.a.out.5; for more details). It
contains three loaded segments: .text, .data, and .bss plus
a symbol table and a string table.</para>
</listitem>
<listitem>
<para><acronym>COFF</acronym></para>
<para>The SVR3 object format. The header now comprises a
section table, so you can have more than just .text, .data,
and .bss sections.</para>
</listitem>
<listitem>
<para>&man.elf.5;</para>
<para>The successor to <acronym>COFF</acronym>, featuring
multiple sections and 32-bit or 64-bit possible values. One
major drawback: <acronym>ELF</acronym> was also designed
with the assumption that there would be only one ABI per
system architecture. That assumption is actually quite
incorrect, and not even in the commercial SYSV world (which
has at least three ABIs: SVR4, Solaris, SCO) does it hold
true.</para>
<para>FreeBSD tries to work around this problem somewhat by
providing a utility for <emphasis>branding</emphasis> a
known <acronym>ELF</acronym> executable with information
about the ABI it is compliant with. See the manual page for
&man.brandelf.1; for more information.</para>
</listitem>
</itemizedlist>
<para>FreeBSD comes from the <quote>classic</quote> camp and used
the &man.a.out.5; format, a technology tried and proven through
many generations of BSD releases, until the beginning of the 3.X
branch. Though it was possible to build and run native
<acronym>ELF</acronym> binaries (and kernels) on a FreeBSD
system for some time before that, FreeBSD initially resisted the
<quote>push</quote> to switch to <acronym>ELF</acronym> as the
default format. Why? Well, when the Linux camp made their
painful transition to <acronym>ELF</acronym>, it was not so much
to flee the <filename>a.out</filename> executable format as it
was their inflexible jump-table based shared library mechanism,
which made the construction of shared libraries very difficult
for vendors and developers alike. Since the
<acronym>ELF</acronym> tools available offered a solution to the
shared library problem and were generally seen as <quote>the way
forward</quote> anyway, the migration cost was accepted as
necessary and the transition made. FreeBSD's shared library
mechanism is based more closely on Sun's
&sunos; style shared library mechanism
and, as such, is very easy to use.</para>
<para>So, why are there so many different formats?</para>
<para>Back in the dim, dark past, there was simple hardware. This
simple hardware supported a simple, small system. <filename>a.out</filename> was
completely adequate for the job of representing binaries on this
simple system (a PDP-11). As people ported &unix; from this simple
system, they retained the <filename>a.out</filename> format because it was sufficient
for the early ports of &unix; to architectures like the Motorola
68k, VAXen, etc.</para>
<para>Then some bright hardware engineer decided that if he could
force software to do some sleazy tricks, then he would be able
to shave a few gates off the design and allow his CPU core to
run faster. While it was made to work with this new kind of
hardware (known these days as <acronym>RISC</acronym>), <filename>a.out</filename>
was ill-suited for this hardware, so many formats were developed
to get to a better performance from this hardware than the
limited, simple <filename>a.out</filename> format could
offer. Things like <acronym>COFF</acronym>,
<acronym>ECOFF</acronym>, and a few obscure others were invented
and their limitations explored before things seemed to settle on
<acronym>ELF</acronym>.</para>
<para>In addition, program sizes were getting huge and disks (and
physical memory) were still relatively small so the concept of a
shared library was born. The VM system also became more
sophisticated. While each one of these advancements was done
using the <filename>a.out</filename> format, its usefulness was
stretched more and more with each new feature. In addition,
people wanted to dynamically load things at run time, or to junk
parts of their program after the init code had run to save in
core memory and swap space. Languages became more sophisticated
and people wanted code called before main automatically. Lots of
hacks were done to the <filename>a.out</filename> format to
allow all of these things to happen, and they basically worked
for a time. In time, <filename>a.out</filename> was not up to
handling all these problems without an ever increasing overhead
in code and complexity. While <acronym>ELF</acronym> solved many
of these problems, it would be painful to switch from the system
that basically worked. So <acronym>ELF</acronym> had to wait
until it was more painful to remain with
<filename>a.out</filename> than it was to migrate to
<acronym>ELF</acronym>.</para>
<para>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 tree
added shared libraries and fixed some bugs. The GNU folks that
originally wrote these programs rewrote them and added simpler
support for building cross compilers, plugging in different
formats at will, and so on. Since many people wanted to build cross
compilers targeting FreeBSD, they were out of luck since the
older sources that FreeBSD had for <application>as</application> and <application>ld</application> were not up to the
task. The new GNU tools chain (<application>binutils</application>) does support cross
compiling, <acronym>ELF</acronym>, shared libraries, C++
extensions, etc. In addition, many vendors are releasing
<acronym>ELF</acronym> binaries, and it is a good thing for
FreeBSD to run them.</para>
<para><acronym>ELF</acronym> is more expressive than <filename>a.out</filename> and
allows more extensibility in the base system. The
<acronym>ELF</acronym> tools are better maintained, and offer
cross compilation support, which is important to many people.
<acronym>ELF</acronym> may be a little slower than <filename>a.out</filename>, but
trying to measure it can be difficult. There are also numerous
details that are different between the two in how they map
pages, handle init code, etc. None of these are very important,
but they are differences. In time support for
<filename>a.out</filename> will be moved out of the <filename>GENERIC</filename>
kernel, and eventually removed from the kernel once the need to
run legacy <filename>a.out</filename> programs is past.</para>
</sect1>
<sect1 xml:id="basics-more-information">
<title>更多資訊</title>