Come interpretare l'output del programma ldd?

[[email protected] 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)

Cosa significa la prima riga e l'ultima riga? Non sembrano il normaleCome interpretare l'output del programma ldd?

xxxx.so => /lib64/xxxxx.so (0xxxxxxxxxxxxxxxxxxxx)

formato.

fonte

2015-12-23 liam xu

Hai provato a leggere la pagina man di ldd? Ti dice esattamente quello che fa. –

Forza ragazzi, questa domanda non riguarda "l'hardware e il software di calcolo generale", ma "coinvolge direttamente [s] strumenti utilizzati principalmente per la programmazione". – 5gon12eder

So cosa fa, ma non so dove posso trovare linux-vdso.so.1 nel mio caso (prima riga), e perché non ci sono frecce puntate su/lib64/ld-linux-x86-64. so.2 (ultima riga). –

ldd filename mostra le librerie condivise del programma utilizzate dal file.

libc.so.6, ad esempio, è la versione 6 dell'oggetto condiviso libc, che si trova in/lib64 e la sua posizione di memoria è 0x00007f70f684f000.

L'ultima riga parla di ld-linux-x86-64.so versione 2 in/lib64. Questo utente troverà e caricherà le librerie condivise node esigenze. Preparerà quelle librerie e le eseguirà. Quindi, parlando in termini molto volgari, ld-linux-x86-64 è il corridore. libc.so.6 e altri sono caricati e ldd mostra la posizione di quelle librerie condivise e posizioni di memoria. Questa è la mia comprensione

fonte

2015-12-23 03:43:02 zedfoxus

la prima riga è VDSO. questo è descritto in profondità nel vdso(7) manpage. in pratica si tratta di una libreria condivisa incorporata nel kernel e caricata automaticamente ogni volta che viene eseguito un nuovo processo. ecco perché non esiste un percorso del filesystem sul lato destro - non ce n'è! il file esiste solo nella memoria del kernel (beh, non preciso al 100%, ma vedere la pagina man per maggiori informazioni).

l'ultima riga è l'interprete ELF. questo è descritto in profondità nello ld.so(8) manpage. la ragione per cui ha un percorso completo è perché il tuo programma ha il percorso completo codificato in esso. il motivo per cui non ha una voce sul lato destro è che non è collegato (direttamente) e quindi non è stata eseguita alcuna ricerca. puoi verificarlo eseguendo:

$ 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

tutte le altre linee sono librerie a cui hai collegato. puoi vedere quelli guardando i tag DT_NEEDED quando esegui readelf -d sul file. poiché questi file non hanno percorsi completi, ld.so deve eseguire una ricerca di percorsi dinamici. questo è in realtà quello che le linee ti dicono: "libdl.so.2 è necessario, quindi quando ho cercato, l'ho trovato a /lib64/libdl.so.2 (ed è stato caricato in memoria all'indirizzo 0x00007f70f7855000)"

fonte

2016-03-04 20:24:25

Come interpretare l'output del programma ldd?

risposta

Problemi correlati