Now that the Handbook has a nice long binary format discussion, remove
the horrible long binary format discussion from the FAQ.
This commit is contained in:
Michael Lucas
parent
6fa84d219b
commit
dd93911fd5
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=17271
1 changed files with 0 additions and 178 deletions
|
|
@ -11076,184 +11076,6 @@ raisechar=^^</programlisting>
|
|||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question id="aout-elf">
|
||||
<para>Why use (what are) a.out and ELF executable
|
||||
formats?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<para>To understand why FreeBSD uses the
|
||||
<filename>ELF</filename> format, you must first know a little
|
||||
about the 3 currently <quote>dominant</quote> executable
|
||||
formats for Unix:</para>
|
||||
|
||||
<note>
|
||||
<para>Prior to FreeBSD 3.X, FreeBSD used the a.out
|
||||
format.</para>
|
||||
</note>
|
||||
|
||||
<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 magic number at the beginning that is often
|
||||
used to characterize the format (see &man.a.out.5;
|
||||
for more details). 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 now comprises
|
||||
a section table, so you can have more than just .text,
|
||||
.data, and .bss sections.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><acronym>ELF</acronym></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 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 has at least three ABIs:
|
||||
SVR4, Solaris, SCO) does it hold true.</para>
|
||||
|
||||
<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 about the ABI it is compliant with. See the
|
||||
manual page for &man.brandelf.1;
|
||||
for more information.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>FreeBSD comes from the <quote>classic</quote> camp and
|
||||
has traditionally used the &man.a.out.5; format, a
|
||||
technology tried and proven through many generations of
|
||||
BSD releases. Though it has also been possible for some
|
||||
time to build and run native <acronym>ELF</acronym>
|
||||
binaries (and kernels) on a FreeBSD system, FreeBSD
|
||||
initially resisted the <quote>push</quote> to switch to
|
||||
<acronym>ELF</acronym> as the default format. Why? Well,
|
||||
when the Linux camp made their painful transition to
|
||||
<acronym>ELF</acronym>, 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 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.</para>
|
||||
|
||||
<para>In FreeBSD's case, our shared library mechanism is based
|
||||
more closely on Sun's <application>SunOS</application>-style
|
||||
shared library mechanism and, as such, is very easy to use.
|
||||
However, starting with 3.0, FreeBSD officially supports
|
||||
<acronym>ELF</acronym> binaries as the default format. Even
|
||||
though the <filename>a.out</filename> executable format has
|
||||
served us well, the GNU people, who author the compiler tools
|
||||
we use, have dropped support for the <filename>a.out</filename>
|
||||
format. This has forced us to maintain a divergent version of
|
||||
the compiler and linker, and has kept us from reaping the
|
||||
benefits of the latest GNU development efforts. Also the
|
||||
demands of ISO-C++, notably constructors and destructors, has
|
||||
also led to native <acronym>ELF</acronym> support in future
|
||||
FreeBSD releases.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question id="binary-formats">
|
||||
<para>Yes, but why are there so many different formats?</para>
|
||||
</question>
|
||||
|
||||
<answer>
|
||||
<para>Back in the dim, dark past, there was simple hardware.
|
||||
This simple hardware supported a simple, small system. a.out
|
||||
was completely adequate for the job of representing binaries on
|
||||
this simple system (a PDP-11). As people ported Unix from this
|
||||
simple system, they retained the a.out format because it was
|
||||
sufficient for the early ports of Unix to architectures like
|
||||
the Motorola 68k, VAXen, etc.</para>
|
||||
|
||||
<para>Then some bright hardware engineer decided that if he
|
||||
could force software to do some sleazy tricks, then he would be
|
||||
able to shave a few gates off the design and allow his CPU core
|
||||
to run faster. While it was made to work with this new kind of
|
||||
hardware (known these days as RISC), <filename>a.out</filename>
|
||||
was ill-suited for this hardware, so many formats were
|
||||
developed to get to a better performance from this hardware
|
||||
than the limited, simple <filename>a.out</filename> format
|
||||
could 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>
|
||||
|
||||
<para>In addition, program sizes were getting huge and disks
|
||||
(and physical memory) were still relatively small so the
|
||||
concept of a shared library was born. The VM system also became
|
||||
more sophisticated. While each one of these advancements was
|
||||
done using the <filename>a.out</filename> format, its
|
||||
usefulness was stretched more and more 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 main
|
||||
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>However, as time passed, the build tools that FreeBSD
|
||||
derived their build tools from (the assembler and loader
|
||||
especially) evolved in two parallel trees. The FreeBSD tree
|
||||
added shared libraries and fixed some bugs. The GNU folks that
|
||||
originally write these programs rewrote them and added simpler
|
||||
support for building cross compilers, plugging in different
|
||||
formats at will, etc. Since many people wanted to build cross
|
||||
compilers targeting FreeBSD, they were out of luck since the
|
||||
older sources that FreeBSD had for as and ld were not up to the
|
||||
task. The new gnu tools chain (binutils) does support cross
|
||||
compiling, <acronym>ELF</acronym>, shared libraries, C++
|
||||
extensions, etc. In addition, many vendors are releasing
|
||||
<acronym>ELF</acronym> binaries, and it is a good thing for
|
||||
FreeBSD to run them. And if it is running
|
||||
<acronym>ELF</acronym> binaries, why bother having
|
||||
<filename>a.out</filename> any more? It is a tired old horse
|
||||
that has proven useful for a long time, but it is time to turn
|
||||
him out to pasture for his long, faithful years of
|
||||
service.</para>
|
||||
|
||||
<para><acronym>ELF</acronym> is more expressive than a.out and
|
||||
will allow more extensibility in the base system. The
|
||||
<acronym>ELF</acronym> tools are better maintained, and offer
|
||||
cross compilation support, which is important to many people.
|
||||
<acronym>ELF</acronym> 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 in how they map
|
||||
pages, handle init code, etc. None of these are very important,
|
||||
but they are differences. In time support for
|
||||
<filename>a.out</filename> will be moved out of the GENERIC
|
||||
kernel, and eventually removed from the kernel once the need to
|
||||
run legacy <filename>a.out</filename> programs is past.</para>
|
||||
</answer>
|
||||
</qandaentry>
|
||||
|
||||
<qandaentry>
|
||||
<question id="chmod-symlinks">
|
||||
<para>Why will chmod not change the permissions on symlinks?</para>
|
||||
|
|
|
|||
Loading…
Reference in a new issue