Откуда идут символы GDB? - PullRequest
0 голосов
/ 01 декабря 2018

Когда я загружаю /usr/bin/ls файл Fedora 28 в GDB, я могу получить доступ к символу abformat_init, даже если он отсутствует в виде строки или в таблице символов двоичного файла.

$ file /usr/bin/ls
/usr/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=d6d0ea6be508665f5586e90a30819d090710842f, stripped, too many notes (256)
$ readelf -S /usr/bin/ls | grep abformat
$ nm /usr/bin/ls
nm: /usr/bin/ls: no symbols
$ strings /usr/bin/ls | grep abformat
$ gdb /usr/bin/ls
[...]
Reading symbols from /usr/bin/ls...Reading symbols from /usr/bin/ls...(no debugging symbols found)...done.
(no debugging symbols found)...done.
Missing separate debuginfos, use: dnf debuginfo-install coreutils-8.29-7.fc28.x86_64
(gdb) info symbol abformat_init 
abformat_init in section .text of /usr/bin/ls

Откуда этот символ?Есть ли программа, которая позволяет извлекать их за пределы GDB?

Ответы [ 2 ]

0 голосов
/ 01 декабря 2018

Существует ли программа, которая позволяет извлекать их за пределы GDB?

Да, вы можете использовать nm для извлечения символа, но вы должны искать символ вотдельный файл информации об отладке, поскольку сам двоичный файл удален.

Вы можете использовать readelf или objdump, чтобы узнать имя отдельного файла отладочной информации, см. Как узнать имя и / или путь кфайл символов отладки, связанный с двоичным исполняемым файлом? :

$ objdump -s -j .gnu_debuglink /usr/bin/ls

/usr/bin/ls:     file format elf64-x86-64

Contents of section .gnu_debuglink:
 0000 6c732d38 2e33302d 362e6663 32392e78  ls-8.30-6.fc29.x
 0010 38365f36 342e6465 62756700 5cddcc98  86_64.debug.\...

На Fedora 29 имя отдельного файла отладочной информации для /usr/bin/ls равно ls-8.30-6.fc29.x86_64.debug.

Обычнов Fedora отдельная информация об отладке установлена ​​в каталог /usr/lib/debug/, поэтому полный путь к файлу отладочной информации: /usr/lib/debug/usr/bin/ls-8.30-6.fc29.x86_64.debug.

Теперь вы можете искать символ с помощью nm:

$ nm /usr/lib/debug/usr/bin/ls-8.30-6.fc29.x86_64.debug | grep abformat_init
0000000000006d70 t abformat_init

Обратите внимание, что отдельная отладочная информация должна быть установлена ​​с debuginfo-install, это то, что вам говорит GDB.

0 голосов
/ 01 декабря 2018

TL; DR:

  1. В двоичных файлах Fedora есть специальный сжатый раздел .gnu_debugdata, который читает GDB и который содержит мини-символы .
  2. Содержимое этого раздела может быть удобно напечатано с помощью eu-readelf -Ws --elf-section /usr/bin/ls

readelf -S /usr/bin/ls | grep abformat

Эта команда выводит разделов .Вы хотите символов вместо:

readelf -s /usr/bin/ls | grep abformat
readelf --all /usr/bin/ls | grep abformat

strings /usr/bin/ls | grep abformat

Strings пытается угадать, что вы хотите, и не выводит все строкинашел в двоичном коде.Посмотрите этот пост и попробуйте:

strings -a /usr/bin/ls | grep abformat

Обновление: Я подтвердил результаты, которые вы наблюдали: abformat нигде не появляется, но GDB знаетоб этом.

Оказывается, есть .gnu_debugdata сжатая секция (описанная здесь ), которая имеет мини-символы .

Чтобы извлечь эти данные, обычно вы должны сделать:

objcopy -O binary -j .gnu_debugdata /usr/bin/ls ls.mini.xz

Однако, что сломано в моей системе (выдает пустой вывод), поэтому вместо этого я использовал dd:

# You may need to adjust the numbers below from "readelf -WS /usr/bin/ls"
dd if=/usr/bin/ls of=ls.mini.xz bs=1 skip=151896 count=3764
xz -d ls.mini.xz
nm ls.mini | grep abformat

Произведено:

00000000000005db0 t abformat_init

КЭД.

Дополнительная информация:

  1. Запутан GDB no debugging symbols адресованв эта ошибка .
  2. objcopy отказ от копирования .gnu_debugdata является предметом этой ошибки .
  3. Там это инструмент, который может удобно выводить эту информацию:

    eu-readelf -Ws --elf-section /usr/bin/ls | grep abformat 37: 0000000000005db0 593 FUNC LOCAL DEFAULT 14 abformat_init

...