To understand why FreeBSD uses the
a.out format, you must
first know a little about the 3 currently "dominant" executable
formats for UNIX:
The oldest and `classic' unix object format. It uses a short and compact header with a magic number at the beginning that's often used to characterize the format (see a.out(5) for more details). It contains three loaded segments: .text, .data, and .bss plus a symbol table and a string table.
The SVR3 object format. The header now comprises a section table, so you can have more than just .text, .data, and .bss sections.
The successor to
COFF, featuring Multiple sections
and 32-bit or 64-bit possible values. One major drawback:
ELF 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.
FreeBSD tries to work around this problem somewhat by
providing a utility for branding a known
executable with information about the ABI it's compliant with.
See the man page for
brandelf for more information.
FreeBSD comes from the "classic" camp and has traditionally used
the a.out 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
ELF binaries (and
kernels) on a FreeBSD system, FreeBSD initially resisted the "push"
to switch to
ELF as the default format. Why? Well,
when the Linux camp made their painful transition to
was not so much to flee the
a.out 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
tools available offered a solution to the shared library
problem and were generally seen as "the way forward" anyway, the
migration cost was accepted as necessary and the transition
In FreeBSD's case, our shared
library mechanism is based more closely on Sun's
SunOS-style shared library mechanism and, as such, is very
easy to use.
However, starting with 3.0, FreeBSD will offically support
binaries as the default format. Even though the
executable format has served us well, the GNU people, who author the
compiler tools we use, have dropped support for the
format. This has forced us to maintain a divergent version of
the compler and linker, and has kept us from reaping the benefits
of the latest GNU development efforts. Also the demands of
ISO-C++, notably contstructors and destructors, has also led to
ELF support in future FreeBSD releases.