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 the
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 ELF
executable with information about the ABI it's compliant with.
See the man page for brandelf(1) for more information.
FreeBSD comes from the "classic" camp and uses 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, no official "push" to switch to
ELF as the default format has, as yet, been made. Why? Well,
when the Linux camp made their painful transition to ELF
, it
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 ELF
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
made.
In FreeBSD's case, it's not quite so simple since our shared
library mechanism is based more closely on Sun's
SunOS
-style shared library mechanism and, as such, is very
easy to use. The only thing we actually lack with a.out
which ELF
would give us is cleaner support for C++ constructors
and destructors, among other similarly esoteric things, and it
simply hasn't become much of a problem yet (and there is quite
a bit of C++ code in FreeBSD's source tree). Should that change,
a migration may, at some point, be more seriously contemplated.