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

Remove the no-longer-relevant section on binary formats, as discussed in

Browse source 
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/binary-formats.html

Submitted by:	Hugh O'Brien <obrien.hugh@gmail.com>
This commit is contained in:
Warren Block 2013-08-29 19:06:59 +00:00
parent a79b58e9c6
commit 7b4b2eca5b
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=42604
1 changed files with 0 additions and 150 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

150
en_US.ISO8859-1/books/handbook/basics/chapter.xml
View file

@ -69,10 +69,6 @@
<para>What devices and device nodes are.</para>
</listitem>
<listitem>
<para>What binary format is used under &os;.</para>
</listitem>
<listitem>
<para>How to read manual pages for more information.</para>
</listitem>
@ -2385,152 +2381,6 @@ Swap: 256M Total, 38M Used, 217M Free, 15% Inuse
<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>