dlopen()¶

Funkcja dlopen() ładuje dynamiczny obiekt dzielony (bibliotekę dzieloną) pliku, o nazwie zawartej w zakończonym znakiem nul łańcuchu filename i zwraca nieprzezroczysty „uchwyt” dla tego obiektu dzielonego. Uchwytu tego używa się z innymi funkcjami z API dlopen, takimi jak dlsym(3), dladdr(3), dlinfo(3) i dlclose().

Jeśli filename wynosi NULL, to zwracany jest uchwyt do głównego programu. Jeśli filename zawiera ukośnik („/”), to jest interpretowana jako (względna lub absolutna) ścieżka. W innych sytuacjach, konsolidator dynamiczny szuka obiektu w następujący sposób (więcej szczegółów w podręczniku ld.so(8)):

•

(tylko ELF) Jeśli wywołujący obiekt (tj. biblioteka współdzielona, lub plik wykonywalny, z którego wywoływane jest dlopen()) zawiera znacznik DT_RPATH, natomiast nie zawiera znacznika DT_RUNPATH, to przeszukiwane są katalogi wypisane w znaczniku DT_RPATH.

•

Jeśli, w momencie uruchomienia tego programu, zdefiniowano zmienną środowiskową LD_LIBRARY_PATH i zawierała ona listę katalogów rozdzielonych dwukropkiem, to przeszukiwane są te katalogi (ze względów bezpieczeństwa, zmienna ta jest ignorowana w przypadku programów z ustawionym bitem set-user-ID lub set-group-ID).

•

(tylko ELF) Jeśli wywołujący obiekt zawiera znacznik DT_RUNPATH, to przeszukiwane są katalogi wypisane w tym znaczniku.

•

Sprawdzany jest plik bufora /etc/ld.so.cache (zarządzany przez ldconfig(8)) pod kątem zawierania wpisu dla filename.

•

Przeszukiwane są katalogi /lib i /usr/lib (w tej kolejności).

Jeśli obiekt określony w filename ma zależności od innych obiektów dzielonych, są one również automatycznie ładowane przez konsolidator dynamiczny, za pomocą tych samych reguł (proces ten może postępować rekurencyjnie, jeśli te obiekty mają z kolei swoje zależności itd.).

We flags należy podać jedną z dwóch poniższych wartości:

RTLD_LAZY

Przeprowadza leniwe dowiązanie. Rozwiązuje symbole jedynie wtedy, gdy wykonywany jest kod, który się do nich odnosi. Jeśli do danego symbolu nic się nie odniesie, to nie zostanie nigdy rozwiązany (leniwe dowiązanie jest wykonywane tylko przy odniesieniach do funkcji; odniesienia do zmiennych są zawsze bezzwłocznie przypisywane przy ładowaniu obiektu dzielonego). Od glibc 2.1.1, znacznik ten jest przesłaniany przez efekt zmiennej środowiskowej LD_BIND_NOW.

RTLD_NOW

Jeśli poda się tę wartość lub zmienna środowiskowa LD_BIND_NOW jest ustawiona na niepusty łańcuch, wszystkie niezdefiniowane symbole obiektu dzielonego są rozwiązywane przed powrotem dlopen(). Jeśli nie da się tego wykonać, zwracany jest błąd.

Ponadto, we flags można zsumować (OR) zero lub więcej z poniższych wartości:

RTLD_GLOBAL

Symbole zdefiniowane za pomocą tego obiektu dzielonego zostaną udostępnione do rozwiązywania symboli kolejno ładowanych obiektów dzielonych.

RTLD_LOCAL

Jest to odwrotność RTLD_GLOBAL, a także wartość domyślna, jeśli nie podano żadnego znacznika. Symbole zdefiniowane w tym obiekcie dzielonym nie są udostępniane do rozwiązywania symboli kolejno ładowanych obiektów dzielonych.

RTLD_NODELETE (od glibc 2.2)

Nie odłącza obiektu dzielonego podczas dlclose(). Statyczne i globalne zmienne obiektu nie są zatem inicjowane ponownie, jeśli obiekt zostanie później przeładowany za pomocą dlopen().

RTLD_NOLOAD (od glibc 2.2)

Nie ładuje obiektu dzielonego. Można to wykorzystać do sprawdzenia, czy obiekt jest już rezydentny (dlopen() zwróci NULL jeśli nie jest, albo uchwyt obiektu jeśli jest). Znacznik może posłużyć również do dodania znaczników do już załadowanego obiektu dzielonego. Przykładowo, wcześniej załadowany obiekt dzielony ze znacznikiem RTLD_LOCAL może być otwarty ponownie z RTLD_NOLOAD | RTLD_GLOBAL.

RTLD_DEEPBIND (od glibc 2.3.4)

Umieszcza dziedzinę przeszukiwania dla symboli, w tym obiekcie dzielonym przed dziedziną globalną. Oznacza to, że samodzielny obiekt będzie preferował używanie swoich symboli, zamiast symboli globalnych o tej samej nazwie w obiektach, które zostały już załadowane.

Jeśli filename wynosi NULL, to zwracany jest uchwyt do głównego programu. Przy przekazaniu tego uchwytu do dlsym(3), powoduje on wyszukiwanie symbolu w głównym programie, następnie we wszystkich obiektach dzielonych załadowanych przy rozruchu programu, a potem we wszystkich obiektach dzielonych załadowanych za pomocą dlopen() ze znacznikiem RTLD_GLOBAL.

Odniesienia symboli w obiekcie dzielonym są rozwiązywane za pomocą (w tej kolejności): symboli w mapie linkowań obiektów załadowanych do głównego programu i jego zależności; symboli w obiektach dzielonych (i ich zależności), które były uprzednio otworzone za pomocą dlopen() i znacznika RTLD_GLOBAL; definicji w samym obiekcie dzielonym (i zależności, które zostały załadowane dla tego obiektu).

Wszelkie symbole globalne w pliku wykonywalnym, które zostały umieszczone w jego tablicy symboli dynamicznych przez ld(1), mogą być użyte również do rozwiązywania odniesień w dynamicznie załadowanym obiekcie dzielonym. Symbole mogą być umieszczone w tablicy symboli dynamicznych albo ponieważ plik wykonywalny skonsolidowano z „-rdynamic” (lub synonimicznie: z „--export-dynamic”), co powoduje umieszczenie wszystkich symboli globalnych pliku wykonywalnego w tablicy symboli dynamicznych, albo z powodu odnotowania przez ld(1) zależności od symbolu w innym obiekcie, podczas konsolidowania statycznego.

Jeśli ten sam obiekt dzielony zostanie powtórnie otworzony za pomocą dlopen(), to zwracany jest ten sam uchwyt obiektu. Dynamiczny konsolidator utrzymuje liczniki odniesień dla uchwytów obiektów, tak więc dynamicznie załadowany obiekt dzielony nie jest dealokowany, dopóki dlclose() nie zostanie na nim wywołany tak wiele razy, jak udanie wywołano na nim dlopen(). Konstruktory (zob. niżej) są wywoływane tylko wtedy, gdy obiekt jest faktycznie ładowany do pamięci (tj. gdy licznik odniesień wzrośnie do 1).

Kolejne wywołanie dlopen(), ładujące ten sam obiekt za pomocą RTLD_NOW, może wymusić rozwiązanie symbolu dla obiektu dzielonego wcześniej załadowanego za pomocą RTLD_LAZY. Podobnie, obiekt uprzednio załadowany za pomocą RTLD_LOCAL może awansować na RTLD_GLOBAL w kolejnym wywołaniu dlopen().

Jeśli dlopen() z jakiegoś powodu zawiedzie, zwróci NULL.

dlmopen()¶

Funkcja ta wykonuje te same zadania co dlopen() — argumenty filename i flags oraz wartości zwraca są takie same, z wyjątkiem różnic opisanych niżej.

Funkcja dlmopen() różni się od dlopen() głównie tym, że akceptuje dodatkowy argument, lmid, który określa listę map linkowań (link-map) (do której można odnosić się również jako namespace), w której obiekt dzielony powinien być załadowany (dla porównania, dlopen() dodaje dynamicznie ładowany obiekt dzielony do tej samej przestrzeni nazw, jak obiekt dzielony, z którego wywołano dlopen()). Typ Lmid_t jest nieprzezroczystym uchwytem odnoszącym się do tej przestrzeni nazw.

Argument lmid jest albo identyfikatorem istniejącej przestrzeni nazw (który można pozyskać za pomocą żądania RTLD_DI_LMID dlinfo(3)) lub jedną z następujących wartości specjalnych:

LM_ID_BASE

Ładuje obiekt dzielony w pierwotnej przestrzeni nazw (tj. w przestrzeni nazw aplikacji).

LM_ID_NEWLM

Tworzy nową przestrzeń nazw i ładuje w niej obiekt dzielony. Obiekt musi być prawidłowo skonsolidowany do odniesień wszystkich innych obiektów dzielonych jakich wymaga, ponieważ nowa przestrzeń nazw jest początkowo pusta.

Jeśli filename wynosi NULL, to jedyną dopuszczalną wartością lmid jest LM_ID_BASE.

dlclose()¶

Funkcja dlclose() zmniejsza licznik odniesień na dynamicznie załadowanych obiektach, do których odnosi się handle.

Jeśli licznik odniesień obiektu spadnie do zera, a żadne symbole w tym obiekcie nie są wymagane przez inne obiekty, obiekt ten jest odłączany po pierwszym wywołaniu dowolnych destruktorów zdefiniowanych dla obiektu (symbole w obiekcie mogą być wymagane przez inny obiekt, ponieważ otworzono go ze znacznikiem RTLD_GLOBAL, a jeden z jego symboli umożliwił relokację w innym obiekcie).

Wszystkie obiekty dzielone załadowane automatycznie, gdy dlopen() przywołano na obiekcie, do którego odnosi się handle, są rekurencyjnie zamykane w ten sam sposób.

Pomyślny powrót z dlclose() nie gwarantuje, że symbole powiązane z handle są usunięte z przestrzeni adresowej wywołującego. Oprócz odniesień wynikających z bezpośrednich wywołań dlopen(), mogły zostać niebezpośrednio załadowane obiekty dzielone (i policzone odniesienia), ze względu na zależności w innych obiektach dzielonych. Tylko gdy wszystkie odniesienia zostały uwolnione, obiekt dzielony może być usunięty z przestrzeni adresowej.

dlmopen() i przestrzenie nazw¶

Lista map linków (link-map) definiuje izolowaną przestrzeń nazw do rozwiązywania symboli przez konsolidator dynamiczny. Wewnątrz przestrzeni nazw, zależny obiekt dzielony jest niebezpośrednio ładowany zgodnie ze zwykłymi regułami, a odniesienia do symboli są podobnie rozwiązywane zgodnie ze zwykłymi regułami, lecz rozwiązywanie to jest ograniczone do definicji zapewnionych przez obiekty, które zostały (bezpośrednio lub niebezpośrednio) załadowane do tej przestrzeni nazw.

Funkcja dlmopen() pozwala na izolację załadowań obiektów — możliwość załadowania obiektu dzielonego do nowej przestrzeni nazw, bez ujawniania reszcie aplikacji symboli udostępnionych przez nowy obiekt. Proszę zauważyć, że użycie znacznika RTLD_LOCAL nie jest wystarczające do tego celu, ponieważ zapobiega ono udostępnieniu symboli obiektu dzielonego dla wszystkich innych obiektów dzielonych. W niektórych przypadkach, zachodzi potrzeba udostępnienia symboli zapewnionych przez dynamicznie załadowany obiekt dzielony dla (podzbioru) innych obiektów dzielonych, bez ujawniania tych symboli całej aplikacji. Można to uzyskać za pomocą oddzielnej przestrzeni nazw i znacznika RTLD_GLOBAL.

Funkcja dlmopen() może służyć również do zapewnienia lepszej izolacji, niż znacznik RTLD_LOCAL. W szczególności, obiekty dzielone załadowane za pomocą RTLD_LOCAL mogą być awansowane do RTLD_GLOBAL, jeśli są zależnościami innego obiektu dzielonego załadowanego ze znacznikiem RTLD_GLOBAL. Z tego względu, RTLD_LOCAL jest niewystarczające do izolowania załadowanego obiektu dzielonego, z wyjątkiem (nieczęstej) sytuacji, gdy ma się całkowitą kontrolę nad wszystkich zależnościami obiektu dzielonego.

Możliwe zastosowania dlmopen() to wtyczki, gdzie autor struktury ładowania wtyczek nie może ufać autorom wtyczek i nie chce, aby jakiekolwiek niezdefiniowane symbole ze struktury wtyczek były rozwiązywane do symboli wtyczek. Kolejne zastosowanie, to ładowanie tego samego obiektu więcej niż raz. Bez korzystania z dlmopen(), wymagałoby to utworzenia odrębnej kopii pliku obiektu dzielonego. Za pomocą dlmopen(), można to uzyskać ładując ten sam plik obiektu dzielonego do różnych przestrzeni nazw.

Implementacja glibc obsługuje co najwyżej 16 przestrzeni nazw.

Funkcje inicjalizacji i kończenia¶

Obiekty dzielone mogą eksportować funkcje za pomocą atrybutów funkcji __attribute__((constructor)) i __attribute__((destructor)). Funkcje konstrukcyjne są wykonywane przed powrotem dlopen(), a funkcje destrukcyjne są wykonywane przez powrotem dlclose(). Obiekty dzielone mogą eksportować wiele konstruktorów i destruktorów, a każdej funkcji można przypisać priorytety, aby określić kolejność wykonywania. Więcej informacji na stronach info gcc (w rozdziale „Function attributes”).

Starszą metodą uzyskiwania (częściowo) tego samego wyniku jest użycie dwóch symboli specjalnych rozpoznawanych przez konsolidator: _init i _fini. Jeśli dynamicznie ładowany obiekt dzielony eksportuje algorytm nazwany _init(), to kod ten jest wykonywany po załadowaniu obiektu dzielonego, przed powrotem dlopen(). Jeśli obiekt dzielony eksportuje algorytm nazwany _fini(), to jest on wywoływany zaraz przed odłączeniem obiektu. W tym przypadku, konieczne jest unikania linkowania wobec rozruchowych plików systemowych, które zawierają domyślne wersje tych plików; można to uczynić za pomocą opcji wiersza poleceń gcc(1) -nostartfiles.

Używanie _init i _fini jest obecnie przestarzałe, na korzyść opisanych wcześniej konstruktorów i destruktorów, które oprócz innych zalet, pozwalają na zdefiniowanie wielu funkcji inicjalizacji i kończenia.

Od glibc 2.2.3, atexit(3) może posłużyć do zarejestrowania uchwytu wyjścia, który jest automatycznie wywoływany przez odłączaniu obiektu dzielonego.

Historia¶

Funkcje te są częścią API dlopen, wywodzącego się z SunOS.

Kod źródłowy programu¶

#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>
#include <gnu/lib-names.h>  /* Definiuje LIBM_SO (będzie to


                               łańcuch podobny do "libm.so.6") */
int
main(void)
{


    void *handle;


    double (*cosine)(double);


    char *error;


    handle = dlopen(LIBM_SO, RTLD_LAZY);


    if (!handle) {


        fprintf(stderr, "%s\n", dlerror());


        exit(EXIT_FAILURE);


    }


    dlerror();    /* Czyści ewentualne istniejące błędy */


    cosine = (double (*)(double)) dlsym(handle, "cos");


    /* Zgodnie ze standardem ISO C, rzutowanie pomiędzy wskaźnikami


       funkcji a 'void *', jak poniżej, daje niezdefiniowany wynik.


       POSIX.1-2001 i POSIX.1-2008 akceptują ten stan rzeczy i proponują


       następujące obejście problemu:


           *(void **) (&cosine) = dlsym(handle, "cos");


       To (niezgrabne) rzutowanie jest zgodne ze standem ISO C i uniknie


       ostrzeżeń kompilatora.


       2013 Technical Corrigendum 1 do POSIX.1-2008 poprawia stan rzeczy,


       wymagając od zgodnych implementacji obsługi rzutowań 'void *'


       do wskaźnika funkcji. Tym niemniej, niektóre kompilatory (np. gcc


       z opcją '-pedantic') mogą narzekać na rzutowanie użyte


       w tym programie. */


    error = dlerror();


    if (error != NULL) {


        fprintf(stderr, "%s\n", error);


        exit(EXIT_FAILURE);


    }


    printf("%f\n", (*cosine)(2.0));


    dlclose(handle);


    exit(EXIT_SUCCESS);
}