如何解释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)

第一行和最后一行是什么意思？ 它们看起来不像正常

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

格式。

Answer 1

第一行是VDSO。 这在vdso（7）联机帮助页中有详细描述。 基本上它是一个嵌入在你的内核中的共享库，并在执行新进程时自动加载。 这就是为什么右侧没有文件系统路径 - 没有！ 该文件仅存在于内核内存中（嗯，不是100％精确，但请参阅手册页以获取更多信息）。

最后一行是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

所有其他行都是您链接的库。 您可以通过在文件上运行readelf -d时查看DT_NEEDED标记来查看这些标记。 由于这些文件缺少完整路径，因此ld.so需要对其执行动态路径搜索。 这实际上是线条告诉你的：“需要libdl.so.2 ，所以当我搜索它时，我在/lib64/libdl.so.2找到它（并被加载到地址0x00007f70f7855000内存中）”

Answer 2

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显示了这些共享库和内存位置的位置。 这是我的理解。