Wie interpretiere ich die Ausgabe des LDD-Programms?

[[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)

Was bedeuten die erste Zeile und die letzte Zeile? Sie sehen nicht wie das normale Format aus. Sie sehen nicht wie das normale Format aus.Wie interpretiere ich die Ausgabe des LDD-Programms?

Quelle

2015-12-23 liam xu

Versuchen Sie ldd Manpage zu lesen? Es sagt Ihnen genau, was es tut. –

Komm schon Leute, diese Frage ist nicht "über allgemeine Computerhardware und -software", sondern sehr viel "bezieht direkt [s] Werkzeuge mit ein, die hauptsächlich für das Programmieren benutzt werden". – 5gon12eder

Ich weiß, was es tut, aber ich weiß nicht, wo finde ich linux-vdso.so.1 in meinem Fall (erste Zeile), und warum es keinen Pfeil auf/lib64/ld-linux-x86-64 zeigt. so.2 (letzte Zeile). –

ldd filename zeigt Ihnen die von der Datei verwendeten gemeinsam genutzten Programmbibliotheken.

libc.so.6 ist zum Beispiel libc shared object Version 6, die in/lib64 sitzt und ihr Speicherort ist 0x00007f70f684f000.

Die letzte Zeile spricht über ld-linux-x86-64.so Version 2 unter/lib64. Dieser Kollege wird gemeinsam genutzte Bibliotheken finden und laden node Bedürfnisse. Es bereitet diese Bibliotheken vor und führt sie aus. Also, sehr grob gesprochen, ist ld-linux-x86-64 der Läufer. libc.so.6 und andere werden geladen und ldd zeigt den Speicherort dieser gemeinsam genutzten Bibliotheken und Speicherorte. Das ist mein Verständnis.

Quelle

2015-12-23 03:43:02 zedfoxus

die erste Zeile ist der VDSO. Dies wird ausführlich in der vdso(7) manpage beschrieben. Im Grunde ist es eine gemeinsame Bibliothek, die in Ihren Kernel eingebettet ist und automatisch geladen wird, wenn ein neuer Prozess ausgeführt wird. deshalb gibt es keinen Dateisystempfad auf der rechten Seite - es gibt keinen! Die Datei existiert nur im Kernel-Speicher (gut, nicht 100% genau, aber siehe die man-Seite für weitere Informationen).

Die letzte Zeile ist der ELF-Interpreter. Dies ist ausführlich in der ld.so(8) manpage beschrieben. Der Grund dafür ist, dass Ihr Programm den vollständigen Pfad fest codiert hat. Der Grund, warum es keinen Eintrag auf der rechten Seite hat, ist, dass es nicht mit (direkt) verlinkt ist und somit keine Suche durchgeführt wurde. Sie können dies überprüfen, indem Sie:

$ 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

alle anderen Zeilen sind Bibliotheken, die Sie gegen verlinkt haben. Sie können diese sehen, indem Sie DT_NEEDED Tags anzeigen, wenn Sie readelf -d für die Datei ausführen. Da diese Dateien keine vollständigen Pfade haben, muss die ld.so eine dynamische Pfadsuche für sie durchführen. das ist eigentlich das, was die Zeilen, die Ihnen sagen: „libdl.so.2 benötigt wird, so dass, wenn ich danach gesucht, fand ich es bei /lib64/libdl.so.2 (und wurde in dem Speicher an der Adresse 0x00007f70f7855000 geladen)“

Quelle

2016-03-04 20:24:25

Wie interpretiere ich die Ausgabe des LDD-Programms?

Antwort

Verwandte Themen