6.3. What is FreeBSD's a.out executable format, and why not ELF?

To understand why FreeBSD uses the a.out format, you must first know a little about the 3 currently "dominant" executable formats for UNIX:

• a.out

  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.

• COFF

  The SVR3 object format. The header now comprises a section table, so you can have more than just .text, .data, and .bss sections.

• ELF

  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.