docs/60805: [patch] handbook/basics: use &man.elf.5;
Josef El-Rayes
josef at daemon.li
Fri Jan 2 01:00:43 UTC 2004
>Number: 60805
>Category: docs
>Synopsis: [patch] handbook/basics: use &man.elf.5;
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: update
>Submitter-Id: current-users
>Arrival-Date: Thu Jan 01 17:00:38 PST 2004
>Closed-Date:
>Last-Modified:
>Originator: Josef El-Rayes
>Release: FreeBSD 4.9-STABLE i386
>Organization:
>Environment:
System: FreeBSD jenny.daemon.li 4.9-STABLE FreeBSD 4.9-STABLE #5: Sun Nov 16 23:10:01 CET 2003 josef at jenny.daemon.li:/usr/obj/usr/src/sys/JENNY i386
>Description:
use &man.elf.5; instead of <acronym>ELF</acronym>
>How-To-Repeat:
>Fix:
--- chapter.sgml.diff begins here ---
--- chapter.sgml.orig Fri Jan 2 00:52:59 2004
+++ chapter.sgml Fri Jan 2 01:35:41 2004
@@ -2227,7 +2227,7 @@
<sect1 id="binary-formats">
<title>Binary Formats</title>
- <para>To understand why FreeBSD uses the <acronym>ELF</acronym>
+ <para>To understand why FreeBSD uses the &man.elf.5;
format, you must first know a little about the three currently
<quote>dominant</quote> executable formats for &unix;:</para>
@@ -2252,11 +2252,11 @@
</listitem>
<listitem>
- <para><acronym>ELF</acronym></para>
+ <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: <acronym>ELF</acronym> was also designed
+ major drawback: &man.elf.5; was also designed
with the assumption that there would be only one ABI per
system architecture. That assumption is actually quite
incorrect, and not even in the commercial SYSV world (which
@@ -2265,7 +2265,7 @@
<para>FreeBSD tries to work around this problem somewhat by
providing a utility for <emphasis>branding</emphasis> a
- known <acronym>ELF</acronym> executable with information
+ known &man.elf.5; executable with information
about the ABI it is compliant with. See the manual page for
&man.brandelf.1; for more information.</para>
</listitem>
@@ -2275,16 +2275,16 @@
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 FreeBSD
+ &man.elf.5; binaries (and kernels) on a FreeBSD
system for some time before that, FreeBSD initially resisted the
- <quote>push</quote> to switch to <acronym>ELF</acronym> as the
+ <quote>push</quote> to switch to &man.elf.5; as the
default format. Why? Well, when the Linux camp made their
- painful transition to <acronym>ELF</acronym>, it was not so much
+ painful transition to &man.elf.5;, it was not so much
to flee the <filename>a.out</filename> executable format as it
was their inflexible jump-table based shared library mechanism,
which made the construction of shared libraries very difficult
for vendors and developers alike. Since the
- <acronym>ELF</acronym> tools available offered a solution to the
+ &man.elf.5; tools available offered a solution to the
shared library problem and were generally seen as <quote>the way
forward</quote> anyway, the migration cost was accepted as
necessary and the transition made. FreeBSD's shared library
@@ -2313,7 +2313,7 @@
offer. Things like <acronym>COFF</acronym>,
<acronym>ECOFF</acronym>, and a few obscure others were invented
and their limitations explored before things seemed to settle on
- <acronym>ELF</acronym>.</para>
+ &man.elf.5;.</para>
<para>In addition, program sizes were getting huge and disks (and
physical memory) were still relatively small so the concept of a
@@ -2329,12 +2329,12 @@
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
+ in code and complexity. While &man.elf.5; solved many
of these problems, it would be painful to switch from the system
- that basically worked. So <acronym>ELF</acronym> had to wait
+ that basically worked. So &man.elf.5; 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>
+ &man.elf.5;.</para>
<para>However, as time passed, the build tools that FreeBSD
derived their build tools from (the assembler and loader
@@ -2346,16 +2346,16 @@
compilers targeting FreeBSD, they were out of luck since the
older sources that FreeBSD had for <application>as</application> and <application>ld</application> were not up to the
task. The new GNU tools chain (<application>binutils</application>) does support cross
- compiling, <acronym>ELF</acronym>, shared libraries, C++
+ compiling, &man.elf.5;, shared libraries, C++
extensions, etc. In addition, many vendors are releasing
- <acronym>ELF</acronym> binaries, and it is a good thing for
+ &man.elf.5; binaries, and it is a good thing for
FreeBSD to run them.</para>
- <para><acronym>ELF</acronym> is more expressive than <filename>a.out</filename> and
+ <para>&man.elf.5; 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
+ &man.elf.5; tools are better maintained, and offer
cross compilation support, which is important to many people.
- <acronym>ELF</acronym> may be a little slower than <filename>a.out</filename>, but
+ &man.elf.5; 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 in how they map
pages, handle init code, etc. None of these are very important,
--- chapter.sgml.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-doc
mailing list