私が思い出したように、a.out フォーマットの最初の問題の 1 つは、テキスト、データ、および bss の 3 つのセクションしかサポートしていなかったことです。 ELF では任意の数 (または少なくともそれ以上) を使用できます。 a.out ヘッダーのフォーマットは、次のような非常に単純なものでした:
word <magic>
word <text size>
word <data size>
word <bss size>
対照的に、ELF 形式には、名前、サイズなどのセクション ヘッダーがあります。
より多くのセクションを持つことで、標準セクションが可能になりますが、必要に応じて、const セクション、コンストラクター セクション、さらには関数ごとに 1 つのセクションも提供されます。
a.out 形式により、共有ライブラリがメモリ内の固定場所を占有することを余儀なくされました。 a.out 共有ライブラリを配布したい場合は、そのアドレス空間を登録する必要がありました。これはパフォーマンスには優れていましたが、まったくスケーリングしませんでした。それがどれほどトリッキーだったか、ご自分の目でお確かめください (linuxjournal)。
対照的に、ELF では、共有ライブラリはメモリ内のどこにでもロードでき、同じコンピュータ上で実行されているさまざまなアプリケーションに対して異なるアドレスにあるように見えることさえあります (コードは物理メモリの 1 か所だけに効果的にロードされます)!これを実現するために、IA-32 アーキテクチャーでは、レジスター (%ebx) を犠牲にする必要があります。共有ライブラリが ELF でより複雑になったことを示すより包括的なリファレンスですが、それはプログラマー側ではなくコンパイラー側の複雑さでした。