Operační systémy 13. Knihovny, spustitelné soubory Obsah: © Milan Keršláger http://www.pslib.cz/ke/slajdy 24.4.2012 http://creativecommons.org/licenses/by-nc-nd/3.0/

Knihovní funkce soustředění funkcí do knihovny snaha o opakované použití kódu první úspěšný pokrok v Pascalu tzv. unity v jazyce C je standardní knihovna (libc) zjednodušuje jazyk, standardizuje šířeji jazyk nemusí být klíčová slova pro I/O apod. problém API, ABI, chyb v knihovních funkcích rozhraní se může měnit

Typy knihoven statické knihovny soubory s příponou .a knihovna se po překladu „přilepí“ k programu obstarává tzv. linker dynamické knihovny soubory s příponou .so (ve Windows DLL) program obsahuje jen seznam knihoven a funkcí při spuštění musí loader zavést též knihovnu bez knihovny program nefunguje knihovna v paměti sdílena mezi více procesy

Dynamické knihovny možnost relokace neví se, kde v adresním prostoru bude místo problém zejména IA-32 (jen 4, resp. 2 GiB) zavaděč rozhodne při startu programu snaha o maximalizaci sdílení knihoven nemusí být možné – kolize s knihovnou, kódem nejvýhodnější rozložení lze vypočítat Linux: prelink, Windows: Microsoft při kompilaci DLL oboje relokace na vhodnou adresy předem zrychlení startu (některých) programů

Loader zavaděč programu do paměti poměrně komplikovaná úloha zejména ve spojitosti s dynamickými knihovnami velký měnící se počet, netriviální optimalizace výsledku typicky samostatný (speciální) program kontrola oprávnění a nároků programu vyřešení nedefinovaných symbolů (+ preload) nakopírování programu a knihoven do paměti nastavení sdílené paměti pro knihovny (cizí, vlastní) předání argumentů z příkazového řádku inicializace registrů a sok na začátek (_start)

Dynamic loading knihovna se zavádí až za běhu programu pomocí speciální funkce nezajišťuje OS, ale sám program rozhoduje programátor modularizace programů problém: co když se knihovna změní za běhu programu?

PIC a PIE Position Independent Code funguje na jakékoliv adrese nepotřebuje tedy relokaci (resp. modifikaci) vyžadována podpora instrukcí s relativní adresou v CPU využíváno u knihoven Position Independent Executable v Linuxu bezpečnostní opatření kód je nahrán na „náhodnou“ adresu na IA-32 silně omezené množství cílových adres ztěžuje některé útoky (přepsání zásobníku)

Spustitelný soubor program ve vykonatelné podobě typicky soubor se strojovým kódem různé formáty (ELF, EXE, ...) též bytecode (Java) nebo skript (interpretace) specifické odlišení od ostatních souborů unixové systémy: nastaveno oprávnění „spustitelný“ Windows: přípona .EXE, .COM atd. specifický obsah pro danou platformu, architekturu systémová volání, instrukční sada, metadata → ABI (binární rozhraní) → též Wine na Linuxu

ELF Executable and Linkable Format původně pro Unix System V jako definované ABI 1999 – zvoleno pro unixové systémy spustitelné soubory, sdílené knihovny, object kód, core flexibilní a rozšiřitelný formát hlavička, segmenty, sekce, data není vztažen k jedné architektuře Linux, PlayStation, Nintendo, OpenVMS, ... nástroje: readelf, objdump, file

EXE Executable několik variant DOS (MZ, NE), Windows (NE, LX, PE), OS/2 (LE, LX) mnoho dalších interních variant, ale i komprimované atd. Windows EXE má na začátku MZ, který vypíše zhruba: „Tento program nelze spustit v prostředí DOSu“ kromě metadat a kódu i další data („resources“) ikony, bitmapy, fonty, HTMl dokument, ... sekce pro různé platformy (viz výše) PE – Portable Executable modifikovaný unixový COFF formát

DLL implementace sdílených knihoven též přípony .OCX (ActiveX control), .DRV (ovladač) stejný formát, jako EXE → PE verze není součástí názvu problémy koexistence různých verzí → DLL hell Microsoft neposkytuje správu, aktualizace atd. snadno sdílitelné mezi stejnými aplikacemi nesnadno sdílitelné mezi různými aplikacemi COM model rozšiřuje koncept DLL knihoven volání funkce v DLL knihovně (jako dlopen v POSIXu) rozšířeno na volání mezi procesy nebo i mezi počítači