Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Nov 2015 18:19:27 +0000 (UTC)
From:      Li-Wen Hsu <lwhsu@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r47756 - head/zh_TW.UTF-8/books/handbook/basics
Message-ID:  <201511071819.tA7IJRVB033031@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: lwhsu (ports committer)
Date: Sat Nov  7 18:19:27 2015
New Revision: 47756
URL: https://svnweb.freebsd.org/changeset/doc/47756

Log:
  Remove the binary format section of Traditoinal Chinese handbook
  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

Modified:
  head/zh_TW.UTF-8/books/handbook/basics/chapter.xml

Modified: head/zh_TW.UTF-8/books/handbook/basics/chapter.xml
==============================================================================
--- head/zh_TW.UTF-8/books/handbook/basics/chapter.xml	Sat Nov  7 17:51:58 2015	(r47755)
+++ head/zh_TW.UTF-8/books/handbook/basics/chapter.xml	Sat Nov  7 18:19:27 2015	(r47756)
@@ -2925,146 +2925,6 @@ Swap: 256M Total, 38M Used, 217M Free, 1
     </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>
 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201511071819.tA7IJRVB033031>