Как интерпретировать вывод программы 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)

формат.


linux gnu ldd binutils
person liam xu    schedule 23.12.2015    source источник
comment
Вы пробовали читать справочную страницу ldd? Он точно говорит вам, что он делает.   -  person Sam Varshavchik    schedule 23.12.2015
comment
Я знаю, что он делает, но я не знаю, где я могу найти linux-vdso.so.1 в моем случае (первая строка) и почему нет стрелки, указывающей на /lib64/ld-linux-x86-64.so. .2(последняя строка).   -  person liam xu    schedule 23.12.2015

Ответы (2)


arrow_upward
26
arrow_downward

первая линия - ВДСО. это подробно описано на справочной странице 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

все остальные строки - это библиотеки, с которыми вы связаны. вы можете увидеть их, посмотрев на теги DT_NEEDED при запуске readelf -d в файле. поскольку в этих файлах отсутствуют полные пути, ld.so должен выполнить для них динамический поиск пути. на самом деле это то, о чем вам говорят строки: "libdl.so.2 нужен, поэтому, когда я искал его, я нашел его по адресу /lib64/libdl.so.2 (и был загружен в память по адресу 0x00007f70f7855000)"

person Mike Frysinger    schedule 04.03.2016

arrow_upward
6
arrow_downward

ldd filename показывает общие библиотеки программы, используемые файлом.

Например, libc.so.6 — это общий объект libc версии 6, который находится в каталоге /lib64 и имеет адрес памяти 0x00007f70f684f000.

Последняя строка говорит о ld-linux-x86-64.so версии 2 в каталоге /lib64. Этот парень найдет и загрузит разделяемые библиотеки, которые нужны node. Он подготовит эти библиотеки и запустит их. Итак, говоря очень грубо, ld-linux-x86-64 является бегуном. libc.so.6 и другие загружены, а ldd показывает расположение этих общих библиотек и областей памяти. Это мое понимание.

person zedfoxus    schedule 23.12.2015