Jak interpretować wyjście programu ldd?

Question

[root@wdctc1281 bin]# ldd node 
     linux-vdso.so.1 => (0x00007fffd33f2000) 
     libdl.so.2 => /lib64/libdl.so.2 (0x00007f70f7855000) 
     librt.so.1 => /lib64/librt.so.1 (0x00007f70f764d000) 
     libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f70f7345000) 
     libm.so.6 => /lib64/libm.so.6 (0x00007f70f7043000) 
     libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70f6e2d000) 
     libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f70f6c10000) 
     libc.so.6 => /lib64/libc.so.6 (0x00007f70f684f000) 
     /lib64/ld-linux-x86-64.so.2 (0x00007f70f7a61000) 

Co oznacza wiersz pierwszy i ostatni? Nie wyglądają one jak normalny format.

Answer 1

ldd filename pokazuje współdzielone biblioteki używane przez plik.

libc.so.6, na przykład, jest libc shared object version 6, który znajduje się w/lib64, a jego lokalizacja pamięci to 0x00007f70f684f000.

Ostatnia linia mówi o ld-linux-x86-64.so wersji 2 pod/lib64. Ten facet znajdzie i załaduje wspólne biblioteki. Przygotuje te biblioteki i uruchomi je. Mówiąc prymitywnym językiem, biegaczem jest ld-linux-x86-64. libc.so.6 i inne są ładowane, a ldd pokazuje położenie tych współużytkowanych bibliotek i lokalizacji pamięci. Tak rozumiem.

Answer 2

pierwsza linia to VDSO. zostało to szczegółowo opisane w vdso(7) manpage. w zasadzie jest to biblioteka współdzielona, ​​która jest osadzona w jądrze i automatycznie ładowana po każdym uruchomieniu nowego procesu. dlatego po prawej stronie nie ma ścieżki systemu plików - nie ma żadnej! plik istnieje tylko w pamięci jądra (cóż, nie w 100% dokładne, ale zobacz stronę podręcznika, aby uzyskać więcej informacji).

ostatnia linia to interpreter ELF. jest to opisane szczegółowo w ld.so(8) manpage. powodem, dla którego ma pełną ścieżkę, jest to, że twój program ma pełną ścieżkę w nim zakodowaną. powodem, dla którego nie ma wpisu po prawej stronie, jest to, że nie jest połączony z (bezpośrednio) i dlatego nie przeprowadzono wyszukiwania. Można to sprawdzić przez wykonanie:

$ readelf -l node | grep interpreter 
     [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] 
$ scanelf -i node 
ET_EXEC /lib64/ld-linux-x86-64.so.2 node 

wszystkie pozostałe linie są biblioteki już połączone przeciw. możesz je zobaczyć, patrząc na tagi DT_NEEDED po uruchomieniu readelf -d w pliku. ponieważ pliki te nie mają pełnych ścieżek, plik ld.so musi wykonać dynamiczne wyszukiwanie ścieżki. tak właśnie mówią linie: "libdl.so.2 jest potrzebny, więc gdy go szukałem, znalazłem go pod adresem /lib64/libdl.so.2 (i został załadowany do pamięci pod adresem 0x00007f70f7855000)"