3.12. Bináris formátumok

Annak megértéséhez, hogy a FreeBSD miért az elf(5) formátumot használja, először is tisztában kell lennünk a UNIX® típusú rendszerekben használt végrehajtható állományok három “uralkodó” formátumával:

• a.out(5)

  A legősibb és egyben a “klasszikus” UNIX-os tárgykódformátum. Egy tömör és rövidke fejlécet használ, aminek az elején a formátum leírására szolgáló “bűvös szám” található (erről bővebben lásd a.out(5)). Három betöltött szegmenst tartalmaz: .text, .data és .bss, valamint egy szimbólumokat és karakterláncokat tároló táblát.

• COFF

  Az SVR3 tárgykódformátuma. A fejléc itt már tartalmaz egy table nevű szegmenst is, tehát a .text, .data és .bss szegmensekhez hasonlóan ebből is többet tud tárolni.

• elf(5)

  A COFF után következő formátum, amelyben több szegmens is megtalálható, valamint létezik 32 bites és 64 bites változatban is. Egyetlen hátránya van: az ELF tervezése során rendszerarchitektúránként csupán egyetlen ABI-t (bináris alkalmazói felületet) feltételeztek. Ez azonban meglehetősen helytelen, mivel még a kereskedelmi SYSV világában (ahol már legalább három ABI található: SVR4, Solaris és SCO) sem állja meg a helyét.

  A FreeBSD ezt a problémát a megbélyegzés (branding) segítségével próbálja megoldani, aminek révén el tudunk látni egy ismert ELF állományt a futtatásához megfelelő ABI-ra vonatkozó információkkal. Erről részletesebben a brandelf(1) oldalán tájékozódhatunk.

A FreeBSD a “klasszikusok” táborából indult, ezért kezdetben az a.out(5) formátumot használta, mivel ez a technológia a BSD kiadások számos generációjában megméretettett és bevált, egészen a 3.X ág elindulásáig. Habár már jóval előtte lehetett fordítani és futtatni natív ELF binárisokat (és rendszermagokat) a FreeBSD rendszereken, a FreeBSD kezdetben óckodott váltani az alapértelmezés szerinti ELF formátumra. De vajon miért? Nos, a linuxos tábor már megtette a maga fájdalmas váltását az ELF formátummal kapcsolatban, és gyorsan maguk mögött hagyták a a.out formátumot a rugalmatlan, ugrótáblákra alapozott oszott könyvtár-kezelési mechanizmusai miatt, amivel viszont megnehezítették a különböző fejlesztők és gyártók számára az osztott könyvtárak létrehozását. Mivel az ELF formátumhoz rendelkezésre álló eszközök megoldást kínáltak az osztott könyvtárak gondjaira, és mivel általánosan elfogadták “a jövőbe vezető útként”, a FreeBSD is felvállalta az átállással kapcsolatos költségeket és végrehajtotta azt. A FreeBSD az osztott könyvtárakat leginkább a Sun SunOS™ rendszeréhez hasonlóan kezeli, ami egy nagyon könnyen használható megoldás.

De miért van ilyen sok különböző formátum?

A ködös és sötét múltban egyszerűbb hardverek voltak. Ezek az egyszerű hardverek egyszerű, kicsi rendszereket támogattak. Az a.out tökéletesen megfelelő volt egy ilyen egyszerű rendszer (egy PDP-11) binárisainak tárolására. Ahogy az emberek nekiláttak átültetni erről az egyszerű rendszerről a UNIX-ot más rendszerekre, az a.out formátumot továbbra is megtartották, mivel a UNIX kezdeti, Motorola 68k-ra, VAXenre készített átírataihoz is elegendő volt.

Ezután néhány éles elméjű hardvermérnök kitalálta, hogy ha rá tudnák kényszeríteni a programokat egy-két ügyetlen trükkre, akkor a terveken meg tudnának spórolni néhány logikai kaput és ezzel processzor is gyorsabban tudna futni. Miközben az a.out formátumot ilyen hardverre (amit manapság RISC-nek hívnak) is szerették volna áthozni, kiderült, hogy ebben az esetben szinte használhatatlan. Ezért az a.out formátum által felkínáltnál nagyobb teljesítmény elérése érdekében nekiláttak számos más formátumot is kidolgozni. Ekkor jöttek létre a COFF, ECOFF és más hasonló formátumok, amelyek előbb-utóbb korlátokba ütköztek még mielőtt a történelem megállapodott volna az ELF formátumnál.

Ráadásul a programok méretei egyre inkább kezdtek nőni, miközben a lemezek (valamint a fizikai memória) továbbra is viszonylag kicsik maradtak, ezért megszületett az osztott könyvtár ötlete és a virtuális memóriát kezelő alrendszer is sokat finomodott. Mivel ezek a különböző fejlesztések a a.out formátumra épültek, annak használatósága a beletömött módosítások számával együtt romlott. Emellett az emberek még szerettek volna betölteni különféle dolgokat futási időben dinamikusan, vagy éppen a memória és a lapozóállomány megspórolásához kipucolni a programjaik egyes részeit az inicializáló kódrészletek lefutása után. A programozási nyelvek is fejlődtek, és az emberek a főprogram futása előtt is akartak kódot futtatni. Az a.out formátum rengeteg apró foltozáson esett keresztül, amelyek egy ideig még tudták is tartani magukat. Azonban egy idő után már az a.out formátum egyre növekvő teljesítménycsökkenés nélkül már nem volt képes állni a sarat. Habár az ELF megszűntette a fennálló problémák jelentős részét, egyúttal megnehezítette egy alapvetően működő rendszer leváltását. Ezért az ELF formátumnak meg kellett várnia azt a pillanatot, amikorra az a.out használata már kényelmetlenné vált.

Azonban ahogy múlt az idő, az eszközökből, amelyekből a FreeBSD a fordításához szükséges eszközöket származtatta (különösen az assembler és a betöltő),létrejött két párhuzamos fejlesztési fa. A FreeBSD-fa kiegészült az osztott könyvtárak támogatásával és hibákat javított, miközben a GNU-fa alkotói, akik eredetileg készítették ezeket a programokat, újraírták az eszközeiket és a keresztfordításhoz egyszerűbb támogatást készítettek, cserélhetővé tették a különböző formátumokat és így tovább. Sokan akartak FreeBSD-re keresztfordítani, azonban nem volt szerencséjük, mert a FreeBSD régebbi forrásait az as és ld már nem emésztette meg. Az új GNU eszköztár (a binutils) viszont ismeri már a keresztfordítást, az ELF formátumot, az oszott könyvtárakat, a C++ kiterjesztéseit stb. Időközben egyre több gyártó ELF formátumú binárisokat adott ki, és jó érzés volt ezeket FreeBSD-n is futtatni.

Az ELF sokkal kifejezőbb az a.out formátumnál és jóval több bővítési lehetőséget enged az alaprendszerben. Az ELF formátumhoz tartozó eszközöt jobban karbantartják és támogatja a keresztfordítást, ami viszont sokaknak fontos. Az ELF talán némileg lassabb, mint az a.out, azonban ez nehezen mérhető le. Számos részletben eltérnek ugyan, például hogyan képeznek le lapokat, hogyan kezelik az inicializáló kódot stb., de ezek egyike sem igazán fontos. Idővel az a.out támogatása ki fog kerülni a GENERIC rendszermagból, és végül majd teljesen eltávolításra kerül, ahogy a régi a.out formátumú programok szépen lassan kifutnak.