web-dev-qa-db-ja.com

lddプログラムの出力をどのように解釈しますか？

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

最初の行と最後の行はどういう意味ですか？彼らは通常のようには見えません

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

フォーマット。

linuxgnubinutilsldd
18
liam xu

最初の行はVDSOです。これについては、 vdso（7）マンページ で詳しく説明されています。基本的には、カーネルに埋め込まれ、新しいプロセスが実行されるたびに自動的にロードされる共有ライブラリです。そのため、右側にファイルシステムパスがありません-ありません！ファイルはカーネルメモリにのみ存在します（100％正確ではありませんが、詳細についてはmanページを参照してください）。

最後の行はELFインタープリターです。これについては、 ld.so（8）マンページ で詳しく説明されています。フルパスがある理由は、プログラムにフルパスがハードコードされているためです。右側にエントリがない理由は、（直接）リンクされていないため、検索が実行されなかったためです。これは、次のコマンドを実行して確認できます。

$ 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

他のすべての行は、リンクしたライブラリです。ファイルに対してDT_NEEDEDを実行すると、readelf -dタグを確認することでそれらを確認できます。これらのファイルにはフルパスがないため、ld.soは動的パス検索を実行する必要があります。 「libdl.so.2が必要なので、検索したところ、/lib64/libdl.so.2で見つかりました（そして、アドレス0x00007f70f7855000でメモリにロードされました）」

21
Mike Frysinger

ldd filenameは、ファイルで使用されるプログラム共有ライブラリを表示します。

たとえば、libc.so.6はlibc共有オブジェクトバージョン6であり、/ lib64にあり、そのメモリ位置は0x00007f70f684f000です。

最後の行では、/ lib64の下にあるld-linux-x86-64.soバージョン2について説明しています。このフェローは、共有ライブラリnodeのニーズを見つけてロードします。それらのライブラリを準備して実行します。したがって、非常に大雑把に言えば、ld-linux-x86-64がランナーです。 libc.so.6などがロードされ、lddはそれらの共有ライブラリの場所とメモリの場所を示します。それが私の理解です。

5
zedfoxus