ASGAUR

To understand why FreeBSD uses the ELF format, you must first know a little about the 3 currently ``dominant'' executable formats for Unix:

• a.out(5)

  The oldest and ``classic'' 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 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 is compliant with. See the man page for brandelf(1) for more information.

FreeBSD comes from the ``classic'' camp and has traditionally used the 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 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 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, 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 officially supports ELF binaries as the default format. Even though the a.out executable format has served us well, the GNU people, who author the compiler tools we use, have dropped support for the a.out 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 ELF support in future FreeBSD releases.