FreeBSD の a.outフォーマットを理解するためには,
まず UNIXにおいて現在 「優勢」な 3種類の実行フォーマットについて
いくらか知っておく必要があります:
最も古く 「由緒正しい」 unix オブジェクトフォーマットです. マジックナンバを含む短くてコンパクトなヘッダが先頭にあり, これがフォーマットの特徴とされています (参照 a.out(5) より詳細な内容があります). ロードされる 3種類のセグメント: .text, .data, .bss と加えてシンボルテーブルと文字列テーブルを 含みます.
SVR3 のオブジェクトフォーマットです. ヘッダは単一の セクションテーブルから成り, .text, .data, .bss セクション以外 の部分を持つことができます.
COFFの後継です. 複数のセクションをサポートし, 32-bit
と 64-bitのいずれの値も可能です. 大きな欠点の一つは, ELF
はそれぞれのシステムアーキテクチャ毎に単一の ABI のみが存在する
という仮定で設計されていることです. この仮定はまったく
正しくありません. 商用の SYSV の世界でさえそうです
(少なくとも SVR4, Solaris, SCO の 3種類の ABI があります).
FreeBSD はこの問題を解決するための試みとして, 既知の ELF
実行ファイルに ABI に応じた情報を 書き加える
ユーティリティを提供しています.
brandelf のマニュアルページ
を参照してください. より多くの情報があります.
FreeBSD は伝統的な立場をとり, 数多くの世代の BSD のリリース
で試され, 実証されてきた
a.outフォーマットを伝統的に使用しています.
いつかは FreeBSDシステムでネイティブ ELF バイナリを作り,
実行することができるようになるかもしれませんが, 初期の頃 FreeBSD
では ELF をデフォルトのフォーマットに変更するという動きは
ありませんでした. なぜでしょうか? ところで Linux においては,
ELF への苦痛をともなった変更は, その時に a.out
実行フォーマットから逃れたというよりは, ジャンプテーブルベース
の共有ライブラリのメカニズムの柔軟性の低さからの脱却でした.
これはベンダや開発者全体にとって共有ライブラリの作成が非常に
難しかった原因でした.
ELFのツールには共有ライブラリの問題を
解決することができるものが提供されており, またいずれにせよ
一般的に「進歩」していると考えられます. このため移行のコストは
必要なものとして容認され, 移行はおこなわれました.
FreeBSDの場合は, 共有ライブラリのメカニズムは Sun の
SunOSスタイルの共有ライブラリのメカニズムに極めて近い
ものになっていて非常に使いやすいものになっています.
しかしながら, FreeBSD では 3.0 から ELF バイナリをデフォルトの
フォーマットとして公式にサポートしています. a.out
実行フォーマットはよいものを私達に提供してくれているものの, 私達の
使っているコンパイラの作者である GNU の人々は a.out フォーマット
のサポートをやめてしまったのでした. このことは, 私達に別バージョンの
コンパイラとリンカを保守することを余儀なくされることとなり, 最新の
GNU 開発の努力による恩恵から遠ざかることになります. その上, ISO-C++
の, とくにコンストラクタやデストラクタがらみの要求もあって, 今後の
FreeBSD のリリースでネイティブの ELF のサポートされる方向へと
話が進んでいます.