From owner-svn-doc-head@FreeBSD.ORG Thu Aug 29 19:07:00 2013 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E5AC6C12; Thu, 29 Aug 2013 19:06:59 +0000 (UTC) (envelope-from wblock@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C360F2192; Thu, 29 Aug 2013 19:06:59 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r7TJ6xWN029251; Thu, 29 Aug 2013 19:06:59 GMT (envelope-from wblock@svn.freebsd.org) Received: (from wblock@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r7TJ6xIk029250; Thu, 29 Aug 2013 19:06:59 GMT (envelope-from wblock@svn.freebsd.org) Message-Id: <201308291906.r7TJ6xIk029250@svn.freebsd.org> From: Warren Block Date: Thu, 29 Aug 2013 19:06:59 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 19:07:00 -0000 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 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 @@ - What binary format is used under &os;. - - - How to read manual pages for more information. @@ -2385,152 +2381,6 @@ Swap: 256M Total, 38M Used, 217M Free, 1 /dev. - - Binary Formats - - 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. - - 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. - - To understand why &os; uses the &man.elf.5; format, the three - currently dominant, executable formats for &unix; - must be described: - - - - &man.a.out.5; - - The oldest and classic &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. - - - - COFF - - The SVR3 object format. The header comprises a section - table which can contain more than just .text, .data, and - .bss sections. - - - - &man.elf.5; - - The successor to COFF, featuring - multiple sections and 32-bit or 64-bit possible values. One - major drawback is that ELF 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. - - &os; tries to work around this problem somewhat by - providing a utility for branding a - known ELF executable with information - about its compliant ABI. Refer to &man.brandelf.1; for more - information. - - - - &os; comes from the classic 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 - ELF binaries and kernels on a &os; system - for some time before that, &os; initially resisted the - push to switch to ELF as the - default format. Why? When Linux made its painful transition to - ELF, 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 ELF tools offered a - solution to the shared library problem and were generally seen - as the way forward, 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. - - So, why are there so many different formats? Back in the - PDP-11 days when simple hardware supported a simple, small - system, a.out was adequate for the job of - representing binaries. As &unix; was ported, the - a.out format was retained because it was - sufficient for the early ports of &unix; to architectures like - the Motorola 68k or VAXen. - - 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. - a.out was ill-suited for this new kind of - hardware, known as RISC. Many formats were - developed to get better performance from this hardware than the - limited, simple a.out format could offer. - COFF, ECOFF, and a few - others were invented and their limitations explored before - settling on ELF. - - 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 - a.out 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 a.out format - to allow all of these things to happen, and they basically - worked for a time. In time, a.out was not - up to handling all these problems without an ever increasing - overhead in code and complexity. While ELF - solved many of these problems, it would be painful to switch - from the system that basically worked. So - ELF had to wait until it was more painful to - remain with a.out than it was to migrate to - ELF. - - 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 - (binutils) supports cross - compiling, ELF, shared libraries, and C++ - extensions. In addition, many vendors release - ELF binaries, and &os; should be able to run - them. - - ELF is more expressive than - a.out and allows more extensibility in the - base system. The ELF tools are better - maintained and offer cross compilation support. - ELF 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 such as how they map pages and handle init - code. - - For More Information