Jakie wywołanie systemowe służy do ładowania bibliotek w systemie Linux?

W stracewyjściach ścieżki do bibliotek wywoływanych przez pliki wykonywalne znajdują się w wywołaniach open(). Czy jest to wywołanie systemowe używane przez pliki wykonywalne, które są dynamicznie połączone? Co dlopen()? open()nie jest to połączenie, które, jak przypuszczam, odegra pewną rolę w wykonywaniu programów.

dlopennie jest wywołaniem systemowym, to funkcja biblioteczna w bibliotece libdl . Wyświetlane są tylko wywołania systemowe strace.

W Linuksie i na wielu innych platformach (szczególnie tych, które używają formatu ELF dla plików wykonywalnych), dlopenjest implementowany poprzez otwarcie biblioteki docelowej open()i odwzorowanie jej w pamięci mmap(). mmap()jest tu naprawdę kluczową częścią, to właśnie włącza bibliotekę do przestrzeni adresowej procesu, aby procesor mógł wykonać swój kod. Ale musisz to zrobić open(), zanim będziesz mógł mmap()!

dlopen nie ma nic wspólnego z bibliotekami współdzielonymi, o których myślisz. Istnieją dwie metody ładowania obiektu udostępnionego:

1. Mówisz linkerowi podczas kompilacji (ld, chociaż zwykle jest on wywoływany przez kompilator), że chcesz korzystać z funkcji z konkretnej biblioteki współdzielonej. Dzięki takiemu podejściu musisz wiedzieć, jaka będzie nazwa biblioteki po uruchomieniu konsolidatora w czasie kompilacji, ale możesz wywoływać funkcje biblioteki tak, jakby były statycznie połączone z twoim programem. Gdy aplikacja jest uruchomiona, dynamiczny linker w czasie wykonywania (ld.so) zostanie wywołany tuż przed mainwywołaniem funkcji i skonfiguruje przestrzeń procesową aplikacji, aby aplikacja znalazła funkcje biblioteki. Wymaga open()to włożenia smarowania, a następnie włożenia mmap()go, a następnie skonfigurowania niektórych tabel odnośników.
2. Powiesz łącznik kompilacji, które chcesz połączyć z libdl, z którego następnie (za pomocą pierwszej metody) może wywołać dlopen()idlsym()Funkcje. Z dlopen dostajesz uchwyt do biblioteki, której możesz następnie użyć z dlsym, aby otrzymać wskaźnik funkcji do określonej funkcji. Ta metoda jest o wiele bardziej skomplikowana dla programisty niż pierwsza metoda (ponieważ musisz wykonać konfigurację ręcznie, a nie linker robi to za ciebie automatycznie), a także jest bardziej delikatna (ponieważ nie dostajesz kompilacji -time sprawdza, czy wywołujesz funkcje z poprawnymi typami argumentów, jak w pierwszej metodzie), ale zaletą jest to, że możesz zdecydować, który obiekt współdzielony ma zostać załadowany w czasie wykonywania (lub nawet czy w ogóle go załadować), dzięki czemu jest to interfejs przeznaczony do funkcji typu wtyczek. Wreszcie interfejs dlopen jest również mniej przenośny niż w inny sposób, ponieważ jego mechanika zależy od dokładnej implementacji dynamicznego linkera (stąd libtool'slibltdl, który próbuje pozbyć się tych różnic).

Obecnie większość systemów operacyjnych korzysta z metody bibliotek współdzielonych wprowadzonej pod koniec 1987 roku przez SunOS-4.0. Ta metoda opiera się na mapowaniu pamięci za pomocą mmap ().

Biorąc pod uwagę fakt, że na początku lat 90. firma Sun przekazała nawet stary kod oparty na a.out (w tym czasie Solaris był już oparty na ELF) ludziom FreeBSD i że ten kod został później przekazany wielu innym systemom (w tym Linuxowi) , możesz zrozumieć, dlaczego nie ma dużej różnicy między platformami.

ltrace -Sanaliza minimalnego przykładu pokazuje, że mmapjest używany w glibc 2.23

W glibc 2.23, Ubuntu 16.04, działający latrace -Sna minimalnym programie, który używa dlopenz:

ltrace -S ./dlopen.out

przedstawia:

dlopen("libcirosantilli_ab.so", 1 <unfinished ...>
SYS_open("./x86_64/libcirosantilli_ab.so", 524288, 06267650550)      = -2
SYS_open("./libcirosantilli_ab.so", 524288, 06267650550)             = 3
SYS_read(3, "\177ELF\002\001\001", 832)                              = 832
SYS_brk(0)                                                           = 0x244c000
SYS_brk(0x246d000)                                                   = 0x246d000
SYS_fstat(3, 0x7fff42f9ce30)                                         = 0
SYS_getcwd("/home/ciro/bak/git/cpp-cheat"..., 128)                   = 54
SYS_mmap(0, 0x201028, 5, 2050)                                       = 0x7f1c323fe000
SYS_mprotect(0x7f1c323ff000, 2093056, 0)                             = 0
SYS_mmap(0x7f1c325fe000, 8192, 3, 2066)                              = 0x7f1c325fe000
SYS_close(3)                                                         = 0
SYS_mprotect(0x7f1c325fe000, 4096, 1)                                = 0

więc natychmiast widzimy, że dlopenwzywa open+ mmap.

To niesamowite ltracenarzędzie śledzi zarówno wywołania biblioteki, jak i wywołania systemowe, dlatego idealnie nadaje się do sprawdzenia, co się dzieje w tym przypadku.

Bliższa analiza pokazuje, że openzwraca deskryptor pliku 3(następny wolny po stdin, out i err).

readnastępnie używa tego deskryptora pliku, ale TODO, dlaczego mmapargumenty są ograniczone do czterech, i nie możemy zobaczyć, który fd został tam użyty, ponieważ jest to piąty argument . stracepotwierdza zgodnie z oczekiwaniami, że 3jest to jeden, i porządek wszechświata jest przywrócony.

Dzielne dusze mogą również odważyć się na kod glibc, ale nie mogłem znaleźć mmapszybkiego grepa i jestem leniwy.

Przetestowano na tym minimalnym przykładzie z kompilacją płyty grzewczej na GitHub .

straceraporty o wywołaniach systemowych (tj. funkcjach implementowanych bezpośrednio przez jądro). Biblioteki dynamiczne nie są funkcją jądra; dlopenjest częścią biblioteki C, a nie jądra. Implementacja dlopenwill call open(która jest wywołaniem systemowym), aby otworzyć plik biblioteki, aby można go było odczytać.