svn commit: r42604 - head/en_US.ISO8859-1/books/handbook/basics
Warren Block
wblock at FreeBSD.org
Thu Aug 29 19:07:00 UTC 2013
Author: wblock
Date: Thu Aug 29 19:06:59 2013
New Revision: 42604
URL: http://svnweb.freebsd.org/changeset/doc/42604
Log:
Remove the no-longer-relevant section on binary formats, as discussed in
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/binary-formats.html
Submitted by: Hugh O'Brien <obrien.hugh at gmail.com>
Modified:
head/en_US.ISO8859-1/books/handbook/basics/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/basics/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/basics/chapter.xml Thu Aug 29 03:56:17 2013 (r42603)
+++ head/en_US.ISO8859-1/books/handbook/basics/chapter.xml Thu Aug 29 19:06:59 2013 (r42604)
@@ -70,10 +70,6 @@
</listitem>
<listitem>
- <para>What binary format is used under &os;.</para>
- </listitem>
-
- <listitem>
<para>How to read manual pages for more information.</para>
</listitem>
</itemizedlist>
@@ -2385,152 +2381,6 @@ Swap: 256M Total, 38M Used, 217M Free, 1
<filename class="directory">/dev</filename>.</para>
</sect1>
- <sect1 id="binary-formats">
- <title>Binary Formats</title>
-
- <para>Typically when a command is passed to the shell, the shell
- will arrange for an executable file to be loaded into memory and
- a new process is created. Executable files can either be a binary
- file (usually created by the linker as part of compiling a program)
- or a shell script (text file to be interpreted by a binary file,
- like &man.sh.1; or &man.perl.1;). The &man.file.1; command can
- usually determine what is inside a file.</para>
-
- <para>Binary files need to have a well defined format for the system
- to be able to use them properly. Part of the file will be the
- executable machine code (the instructions that tell the CPU what
- to do), part of it will be data space with pre-defined values,
- part will be data space with no pre-defined values, etc. Through
- time, different binary file formats have evolved.</para>
-
- <para>To understand why &os; uses the &man.elf.5; format, the three
- currently <quote>dominant</quote>, executable formats for &unix;
- must be described:</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
- &man.magic.5; number at the beginning that is often used to
- characterize the format. 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 comprises a section
- table which can contain 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 is that <acronym>ELF</acronym> was designed
- with the assumption that there would be only one ABI per
- system architecture. That assumption is actually incorrect,
- and not even in the commercial SYSV world (which has at
- least three ABIs: SVR4, Solaris, SCO) does it hold
- true.</para>
-
- <para>&os; tries to work around this problem somewhat by
- providing a utility for <emphasis>branding</emphasis> a
- known <acronym>ELF</acronym> executable with information
- about its compliant ABI. Refer to &man.brandelf.1; for more
- information.</para>
- </listitem>
- </itemizedlist>
-
- <para>&os; 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 &os; system
- for some time before that, &os; initially resisted the
- <quote>push</quote> to switch to <acronym>ELF</acronym> as the
- default format. Why? When Linux made its painful transition to
- <acronym>ELF</acronym>, it was due to their inflexible
- jump-table based shared library mechanism, which made the
- construction of shared libraries difficult for vendors and
- developers. Since <acronym>ELF</acronym> tools offered a
- solution to the shared library problem and were generally seen
- as <quote>the way forward</quote>, the migration cost was
- accepted as necessary and the transition made. &os;'s shared
- library mechanism is based more closely on the &sunos; style
- shared library mechanism and is easy to use.</para>
-
- <para>So, why are there so many different formats? Back in the
- PDP-11 days when simple hardware supported a simple, small
- system, <filename>a.out</filename> was adequate for the job of
- representing binaries. As &unix; was ported, the
- <filename>a.out</filename> format was retained because it was
- sufficient for the early ports of &unix; to architectures like
- the Motorola 68k or VAXen.</para>
-
- <para>Then some hardware engineer decided that if he could force
- software to do some sleazy tricks, a few gates could be shaved
- off the design and the CPU core could run faster.
- <filename>a.out</filename> was ill-suited for this new kind of
- hardware, known as <acronym>RISC</acronym>. Many formats were
- developed to get better performance from this hardware than the
- limited, simple <filename>a.out</filename> format could offer.
- <acronym>COFF</acronym>, <acronym>ECOFF</acronym>, and a few
- others were invented and their limitations explored before
- settling on <acronym>ELF</acronym>.</para>
-
- <para>In addition, program sizes were getting huge while disks
- and physical memory were still relatively small, so the concept
- of a shared library was born. The virtual memory system became
- more sophisticated. While each advancement was done using the
- <filename>a.out</filename> format, its usefulness was stretched
- 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 the main() function 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>As time passed, the build tools that &os; derived their
- build tools from, especially the assembler and loader, evolved
- in two parallel trees. The &os; 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 and plugging in different formats. Those who
- wanted to build cross compilers targeting &os; were out of luck
- since the older sources that &os; had for &man.as.1; and
- &man.ld.1; were not up to the task. The new GNU tools chain
- (<application>binutils</application>) supports cross
- compiling, <acronym>ELF</acronym>, shared libraries, and C++
- extensions. In addition, many vendors release
- <acronym>ELF</acronym> binaries, and &os; should be able 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.
- <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 such as how they map pages and handle init
- code.</para>
- </sect1>
-
<sect1 id="basics-more-information">
<title>For More Information</title>
More information about the svn-doc-head
mailing list