Dynamisk linker - Dynamic linker

I computing er en dynamisk linker den del af et operativsystem, der indlæser og forbinder de delte biblioteker, der er nødvendige for en eksekverbar, når den eksekveres (på " løbetid "), ved at kopiere bibliotekernes indhold fra vedvarende lagring til RAM , fylde spring borde og flyttepunkter . Det specifikke operativsystem og det eksekverbare format bestemmer, hvordan den dynamiske linker fungerer, og hvordan den implementeres.

Tilknytning omtales ofte som en proces, der udføres, når den eksekverbare kompileres , mens en dynamisk linker er en særlig del af et operativsystem, der indlæser eksterne delte biblioteker i en løbende proces og derefter binder disse delte biblioteker dynamisk til den løbende proces . Denne tilgang kaldes også dynamisk sammenkædning eller sen sammenkædning .

Implementeringer

Microsoft Windows

Hovedartikel: Dynamic-link-bibliotek

Dynamic-link library , eller DLL, er Microsofts implementering af det delte biblioteks koncept i Microsoft Windows og OS/2 operativsystemer . Disse biblioteker har normalt filtypenavnet DLL , OCX(for biblioteker, der indeholder ActiveX- kontroller), eller DRV(for ældre systemer drivere ). Filformaterne til DLL'er er de samme som for Windows EXE- filer-det vil sige Portable Executable (PE) til 32-bit og 64-bit Windows og New Executable (NE) til 16-bit Windows. Som med EXE'er kan DLL'er indeholde kode , data og ressourcer i enhver kombination.

Data, filer med det samme filformat som en DLL, men med forskellige filtyper og eventuelt kun indeholder ressource sektioner, kan kaldes ressource DLL-filer. Eksempler på sådanne DLLs omfatter ikon biblioteker, nogle gange at have en forlængelse ICL, og skrifttype -filer, som har de udvidelser FONog FOT.

Unix-lignende systemer ved hjælp af ELF og Darwin-baserede systemer

I de fleste Unix-lignende systemer er det meste af maskinkoden, der udgør den dynamiske linker, faktisk en ekstern eksekverbar, som operativsystemet kerne indlæser og udfører først i et procesadresserum, der er nybygget som følge af opkald execeller posix_spawnfunktioner. På linktidspunktet er stien til den dynamiske linker, der skal bruges, integreret i det eksekverbare billede.

Når en eksekverbar fil indlæses, læser operativsystemets kerne stien til den dynamiske linker fra den og forsøger derefter at indlæse og eksekvere denne anden eksekverbare binær; hvis forsøget mislykkes, fordi der f.eks. ikke er nogen fil med den sti, mislykkes forsøget på at udføre den originale eksekverbare fil. Den dynamiske linker indlæser derefter det første eksekverbare billede og alle de dynamisk linkede biblioteker, som det afhænger af, og starter den eksekverbare. Som et resultat er stinavnet på den dynamiske linker en del af operativsystemets applikationsbinære grænseflade .

Systemer, der anvender ELF

I Unix-lignende systemer, der bruger ELF til eksekverbare billeder og dynamiske biblioteker, såsom Solaris , 64-bit versioner af HP-UX , Linux , FreeBSD , NetBSD , OpenBSD og DragonFly BSD , stien til den dynamiske linker, der skal bruges er indlejret ved link tid i .interpsektionen af ​​den eksekverbare PT_INTERPsegment. I disse systemer kan dynamisk indlæste delte biblioteker identificeres med filnavnsuffikset .so(delt objekt).

Den dynamiske linker kan påvirkes til at ændre sin adfærd under enten programmets udførelse eller programmets sammenkædning, og eksemplerne på dette kan ses på de manuelle sider i løbetiden til forskellige Unix-lignende systemer. En typisk ændring af denne adfærd er brugen af LD_LIBRARY_PATHog LD_PRELOAD miljøvariabler , der justerer runtime -forbindelsesprocessen ved at søge efter delte biblioteker på alternative steder og ved tvang at indlæse og forbinde biblioteker, der ellers ikke ville være henholdsvis. Et eksempel er zlibc, også kendt som uncompress.so, hvilket letter gennemsigtig dekomprimering, når det bruges gennem LD_PRELOAD hacket ; følgelig er det muligt at læse forudkomprimerede (gzipped) fildata på BSD- og Linux-systemer, som om filerne ikke var komprimeret, hvilket i det væsentlige tillader en bruger at tilføje gennemsigtig komprimering til det underliggende filsystem, dog med nogle forbehold. Mekanismen er fleksibel, hvilket tillader triviel tilpasning af den samme kode til at udføre yderligere eller alternativ behandling af data under den læste fil, før dataene tilvejebringes til den brugerproces, der har anmodet om det.

macOS og iOS

I Apple Darwin- operativsystemet og i macOS- og iOS- operativsystemerne, der er bygget oven på det, er stien til den dynamiske linker, der skal bruges, integreret ved linktid i en af Mach-O- lastkommandoerne i det eksekverbare billede. I disse systemer kan dynamisk indlæste delte biblioteker identificeres enten med filnavnsuffikset .dylibeller ved deres placering inde i bundtet for en ramme.

Den dynamiske linker forbinder ikke kun det eksekverbare mål med de delte biblioteker, men placerer også maskinkodefunktioner på bestemte adressepunkter i hukommelsen, som målets eksekverbare kender til på linktidspunktet. Når en eksekverbar fil ønsker at interagere med den dynamiske linker, udfører den simpelthen den maskinspecifikke opkalds- eller springinstruktion til et af de velkendte adressepunkter. De eksekverbare filer på macOS- og iOS -platformene interagerer ofte med den dynamiske linker under udførelsen af ​​processen; det er endda kendt, at en eksekverbar fil kan interagere med den dynamiske linker, hvilket får den til at indlæse flere biblioteker og løse flere symboler, timer efter at den oprindeligt blev lanceret. Grunden til, at et macOS- eller iOS-program interagerer med den dynamiske linker så ofte, skyldes både Apples Cocoa og Cocoa Touch API'er og Objective-C , det sprog, de implementeres på (se deres hovedartikler for mere information).

Den dynamiske linker kan tvinges til at ændre noget af sin adfærd; i modsætning til andre Unix-lignende operativsystemer er disse ændringer imidlertid tip, der kan (og nogle gange) ignoreres af den dynamiske linker. Eksempler på dette kan ses på dyld's manual side. En typisk ændring af denne adfærd er brugen af DYLD_FRAMEWORK_PATHog DYLD_PRINT_LIBRARIESmiljøvariabler. Den tidligere af de tidligere nævnte variabler justerer eksekverbarernes søgesti for de delte biblioteker, mens sidstnævnte viser navnene på bibliotekerne, når de indlæses og forbindes.

Apples macOS dynamiske linker er et open source-projekt udgivet som en del af Darwin og kan findes i Apples open source- dyldprojekt.

XCOFF-baserede Unix-lignende systemer

I Unix-lignende operativsystemer, der bruger XCOFF , f.eks. AIX , bruger dynamisk indlæste delte biblioteker filnavnets suffiks .a.

Den dynamiske linker kan påvirkes til at ændre sin adfærd under enten programmets udførelse eller programmets sammenkædning. En typisk ændring af denne adfærd er brugen af LIBPATH miljøvariablen . Denne variabel justerer runtime -forbindelsesprocessen ved at søge efter delte biblioteker på alternative placeringer og ved tvang at indlæse og forbinde biblioteker, der ellers ikke ville være henholdsvis.

OS/360 og efterfølgere

Dynamisk forbindelse fra Assembler -sprogprogrammer i IBM OS/360 og dets efterfølgere udføres typisk ved hjælp af en LINK -makroinstruktion, der indeholder en Supervisor Call -instruktion, der aktiverer operativsystemets rutiner, der gør biblioteksmodulet tilgængeligt til programmet. Biblioteksmoduler kan opholde sig i et "STEPLIB" eller "JOBLIB", der er angivet i kontrolkort og kun er tilgængelige for en bestemt udførelse af programmet, i et bibliotek, der er inkluderet i LINKLISTEN i PARMLIB (angivet ved systemstarttid) eller i " link pack area ", hvor specifikke reentrant -moduler indlæses ved systemstarttidspunkt.

Multics

I Multics -operativsystemet er alle filer, inklusive eksekverbare filer, segmenter . Et opkald til en rutine, der ikke er en del af det aktuelle segment, får systemet til at finde det refererede segment i hukommelsen eller på disken og tilføje det til adresserummet i den igangværende proces. Dynamisk sammenkædning er den normale driftsmåde, og statisk forbindelse (ved hjælp af bindemidlet ) er undtagelsen.

Effektivitet

Dynamisk sammenkædning er generelt langsommere (kræver flere CPU -cyklusser) end sammenkædning under kompileringstid, som det er tilfældet for de fleste processer, der udføres under runtime. Imidlertid er dynamisk sammenkædning ofte mere pladsbesparende (på disk og i hukommelse ved runtime). Når et bibliotek er forbundet statisk, er hver proces, der køres, forbundet med sin egen kopi af biblioteksfunktionerne. Derfor, hvis et bibliotek bliver kaldt til mange gange af forskellige programmer, kopieres de samme funktioner i det bibliotek flere steder i systemets hukommelse. Brug af delte, dynamiske biblioteker betyder, at i stedet for at linke hver fil til sin egen kopi af et bibliotek ved kompileringstid og muligvis spilde hukommelsesplads, bliver der kun gemt en kopi af biblioteket i hukommelsen ad gangen, hvilket frigør hukommelsesplads til bruges andre steder. Derudover indlæses et bibliotek kun i dynamisk sammenkædning, hvis det faktisk bruges.

Se også

Noter

Referencer

Yderligere læsning

eksterne links