svn commit: r43206 - head/ja_JP.eucJP/books/handbook/basics
Ryusuke SUZUKI
ryusuke at FreeBSD.org
Tue Nov 19 10:17:11 UTC 2013
Author: ryusuke
Date: Tue Nov 19 10:17:10 2013
New Revision: 43206
URL: http://svnweb.freebsd.org/changeset/doc/43206
Log:
- Merge the following from the English version:
r17170 -> r17270 head/ja_JP.eucJP/books/handbook/basics/chapter.xml
Binary Formats section is not translated and commented out.
This section will be removed from this chapter.
Modified:
head/ja_JP.eucJP/books/handbook/basics/chapter.xml
Modified: head/ja_JP.eucJP/books/handbook/basics/chapter.xml
==============================================================================
--- head/ja_JP.eucJP/books/handbook/basics/chapter.xml Tue Nov 19 10:07:16 2013 (r43205)
+++ head/ja_JP.eucJP/books/handbook/basics/chapter.xml Tue Nov 19 10:17:10 2013 (r43206)
@@ -3,7 +3,7 @@
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
- Original revision: r17170
+ Original revision: r17270
$FreeBSD$
-->
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="basics">
@@ -1622,6 +1622,149 @@ console none
</sect2>
</sect1>
+<!--
+ <sect1 id="binary-formats">
+ <title>Binary Formats</title>
+
+ <para>To understand why FreeBSD uses the <filename>ELF</filename>
+ format, you must first know a little about the 3 currently
+ <quote>dominant</quote> executable formats for Unix:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>&man.a.out.5;</para>
+
+ <para>The oldest and <quote>classic</quote> Unix object
+ format. 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><acronym>ELF</acronym></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
+ <application>SunOS</application>-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. a.out 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 a.out 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 RISC), <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 write these programs rewrote them and added simpler
+ support for building cross compilers, plugging in different
+ formats at will, etc. Since many people wanted to build cross
+ compilers targeting FreeBSD, they were out of luck since the
+ older sources that FreeBSD had for as and ld were not up to the
+ task. The new gnu tools chain (binutils) 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 a.out 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 a.out, 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 GENERIC
+ 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>
More information about the svn-doc-all
mailing list