Date: Thu, 29 Aug 2013 19:06:59 +0000 (UTC) From: Warren Block <wblock@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r42604 - head/en_US.ISO8859-1/books/handbook/basics Message-ID: <201308291906.r7TJ6xIk029250@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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@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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201308291906.r7TJ6xIk029250>