svn commit: r42604 - head/en_US.ISO8859-1/books/handbook/basics

Warren Block wblock at
Thu Aug 29 19:07:00 UTC 2013

Author: wblock
Date: Thu Aug 29 19:06:59 2013
New Revision: 42604

  Remove the no-longer-relevant section on binary formats, as discussed in
  Submitted by:	Hugh O'Brien <obrien.hugh at>


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 @@
-	<para>What binary format is used under &os;.</para>
-      </listitem>
-      <listitem>
 	<para>How to read manual pages for more information.</para>
@@ -2385,152 +2381,6 @@ Swap: 256M Total, 38M Used, 217M Free, 1
       <filename class="directory">/dev</filename>.</para>
-  <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 &; 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 &; 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-all mailing list