Om te kunnen begrijpen waarom FreeBSD gebruik maakt van het elf(5) formaat, is het belangrijk op de hoogte zijn van de drie “dominante” uitvoerbare formaten voor UNIX®:
Het oudste en “klassieke” UNIX® object formaat. Het gebruikt een korte en compacte kop met een magisch nummer aan het begin dat veel gebruikt wordt om het formaat aan te geven (a.out(5) geeft meer details). Het bevat drie laadbare segmenten: .tekst, .data en .bss, een symbolentabel en een stringtabel.
COFF
Het SVR3 object formaat. De kop bestaat uit een sectietabel, dus er kunnen meer dan alleen .tekst, .data, en .bss secties zijn.
De opvolger van COFF, heeft meerdere secties en 32-bit of 64-bit als mogelijke waarden. Één nadeel: ELF was ook ontworpen met de aanname dat er maar één ABI per systeemarchitectuur zou zijn. Deze aanname is eigenlijk redelijk incorrect, zelfs niet in de commerciële SYSV wereld (die op zijn minst drie ABIs heeft: SRV4, Solaris en SCO).
FreeBSD probeert om dit probleem heen te werken door een hulpprogramma te leveren voor het brandmerken van een bekend ELF uitvoerbaar bestand met informatie over de ABI waar hij mee kan werken. In brandelf(1) staat meer informatie.
FreeBSD komt uit het “klassieke” kamp en gebruikt
het a.out(5) formaat, een technologie die zich bewezen heeft
door meerdere generaties van BSD versies heen, tot het begin van
de 3.X versies. Alhoewel het al mogelijk was om
ELF programma's en kernels te bouwen en te
draaien op een FreeBSD systeem , verzette FreeBSD zich eerst tegen de
druk om over te schakelen naar ELF als
standaard formaat. Waarom? Toen het Linux® kamp hun pijnlijke
wissel maakte naar ELF, was dat niet zozeer
om van het a.out
formaat af te komen, maar
meer omdat van het op de inflexibele jump-tabel gebaseerde
gedeelde bibliotheekmechanisme af te komen, die het maken van
gedeelde bibliotheken erg moeilijk maakte voor bedrijven en
ontwikkelaars. Omdat de ELF hulprogramma's
een oplossing voor het gedeelde bibliotheek probleem waren en
algemeen gezien werden als een “stap vooruit”,
werd de migratie geaccepteerd als noodzakelijk kwaad en werd de
wissel uitgevoerd. Het gedeelde bibliotheek mechanisme van FreeBSD
is meer gebaseerd op het gedeelde bibliotheek mechanisme van
Sun's SunOS™ en daardoor erg makkelijk te gebruiken.
Waarom zijn er zoveel verschillende formaten?
In het duistere donkere verleden was er simpele hardware.
Deze simpele hardware ondersteunde een simpel klein systeem.
a.out
was volledig adequaat voor de taak om
binaire bestanden op dat simpele systeem te vertegenwoordigen
(een PDP-11). Toen mensen UNIX® van deze machine gingen porten,
behielden ze het a.out
formaat omdat het
voldeed voor de vroege ports van UNIX® naar architecturen
als Motorola 68k, VAXen, enzovoort.
Toen besloot een slimme hardware engineer dat als hij de
software kon forceren om wat simpele truckjes te doen, hij in
staat was om een paar onderdelen van het ontwerp af te schaven,
waardoor zijn processorcore sneller kon draaien. Terwijl men
probeerde om het met deze nieuwe vorm van hardware te laten
werken (vandaag de dag beter bekend als RISC),
was a.out
te beperkt voor deze hardware.
Dus werden er vele formaten ontworpen om betere prestaties te
krijgen uit deze hardware dan het simpele formaat
a.out
kon leveren. Toen werden
COFF, ECOFF en een paar
andere duistere formaten uitgevonden en werden de limieten
verkend, waarna men besloot om zich te richten op
ELF.
Daarnaast werden programma's groter en bleven schijven (en
fysiek geheugen) relatief klein, zodat het concept van een
gedeelde bibliotheek werd geboren. Het VM systeem werd ook meer
verfijnd. Terwijl al deze verbeteringen bereikt werden door het
a.out
formaat, werd het nut met elke nieuwe
eigenschap verder uitgerekt. Daarnaast wilde men dingen
dynamisch laden tijdens het starten of delen weggooien nadat het
programma zijn intiële code had gedraaid om te blijven
hangen in het hoofdgeheugen en in de wisselbestanden. Talen
werden verder verfijnd en men wilde dat code automatisch werd
aangeroepen voor main. Er werden veel hacks gedaan in het
a.out
formaat om alles mogelijk te maken en
dit werkte ook enige tijd. Na verloop van tijd was
a.out
niet meer in staat om alle problemen
te adresseren zonder toenemende overhead in code en
complexibiliteit. Hoewel ELF veel van deze
problemem verhielp, was het moeilijk om te wisselen naar een
systeem dat compleet anders werkte. Dus moest
ELF wachten totdat het pijnlijker was om
a.out
te behouden dan het te migreren naar
ELF.
Met het verstrijken van de tijd, werden de bouwprogramma's die FreeBSD heeft afgeleid van hun bouwprogramma's (vooral de assembler en de loader) ontwikkeld in twee parallel lopende takken. De FreeBSD tree voegde gedeelde bibliotheken toe en heeft wat bugs opgelost. De mensen van GNU die deze programma's hebben geschreven, hebben ze herschreven en simpelere ondersteuning toegevoegd voor het bouwen van cross-compilers, waarbij verschillende formaten zo nodig ingevoegd konden worden, enzovoort. Omdat veel mensen cross-compilers wilden bouwen die gericht waren op FreeBSD, hadden die pech, omdat de oudere broncode van FreeBSD voor as en ld niet opgewassen was tegen deze taak. De nieuwe GNU programmaketen (binutils) ondersteunt cross-compiling, ELF, gedeelde bibliotheken, C++ extensies, enzovoort. Daarnaast leveren veel leverancierds ELF binaire bestanden en is het goed voor FreeBSD om het te draaien.
ELF heeft meer expressiemogelijkheden dan
a.out
en geeft meer
uitbreidingsmogelijkheden aan het basissysteem. De
ELF hulpprogramma's worden beter onderhouden
en geven de mogelijkheid tot ondersteuning voor cross compilatie,
wat voor veel mensen belangrijk is. ELF is
misschien iets trager dan a.out
, maar
het meten daarvan kan vrij lastig zijn. Er zijn ook ontelbare
verschillen tussen de twee in hoe ze pages opslaan,
initiële code verwerken, enzovoort. Geen van allen zijn ze
erg belangrijk, maar er zijn verschillen. Na verloop van tijd
verdwijnt de ondersteuning voor a.out
uit de
GENERIC
kernel en uiteindelijk ook helemaal
uit de kernel als de noodzaak voor a.out
gebaseerde programma's voorbij is.
All FreeBSD documents are available for download at http://ftp.FreeBSD.org/pub/FreeBSD/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.