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

- Merge the following from the English version:

Browse source 
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.
This commit is contained in:
Ryusuke SUZUKI 2013-11-19 10:17:10 +00:00
parent f455899c00
commit 2a4edf0513
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=43206
1 changed files with 144 additions and 1 deletions

145
ja_JP.eucJP/books/handbook/basics/chapter.xml
View file

@ -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 unknown off secure</programlisting>
</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>