Почему gdb отказывается загружать мои общие объекты и какова операция проверки

#gdb #embedded #dynamic-linking #qnx #shared-objects

#gdb #встроенный #динамическое связывание #qnx #общие объекты

Вопрос:

Основной вопрос:

В Ubuntu при попытке отладки встроенного приложения, работающего в QNX, я получаю следующее сообщение об ошибке от gdb:

warning: Shared object "$SOLIB_PATH/libc.so.4" could not be validated and will be ignored. ,

Вопрос: Что такое операция «проверки» происходит?

После некоторых исследований я обнаружил, что информация, сообщаемая с помощью readelf -n libfoo.so , содержит идентификатор сборки и что это сравнивается с чем-то, и может быть несоответствие, из-за которого gdb отказывается загружать библиотеку. Если это так, с каким идентификатором сборки файла ELF сравнивается идентификатор сборки общего объекта? Могу ли я найти эту информацию при разборе исполняемого файла?

Больше контекста:

У меня есть файл .core для этого исполняемого файла. Я использую версию gdb, предоставленную QNX, и проверяю set sysroot , использую ли я и set solib-search-path куда я установил набор инструментов QNX.

Моя полная команда для запуска gdb в Ubuntu :

$QNX_TOOLCHAIN_PATH/ntox86_64-gdb --init-eval-command 'set sysroot $SYSROOT_PATH' --init-eval-command 'set solib-search-path $SOLIB_PATH --init-eval-command 'python sys.path.append("/usr/share/gcc-8/python");' -c path-to-exe.core path-to-executable-bin

Gdb жалуется, что не может загрузить общие объекты :

warning: Shared object "$SOLIB_PATH/libc.so.4" could not be validated and will be ignored.

Ответ №1:

Здесь важно убедиться, что вы используете точно такой же двоичный файл, который находится на цели (над которым выполняется программа). Это часто бывает довольно сложно с libc, особенно потому, что libc / ldqnx иногда являются «одним и тем же», и это сбивает с толку gdb.

Самый простой способ сделать это — зарегистрировать ваш вывод mkifs (на хосте Linux):

 make 2>amp;1 | tee build-out.txt
  

и прочитайте это, найдите libc.so.4 и скопируйте двоичный файл, который переносится на цель. (где бы вы ни запускали gdb), поэтому вам не нужно связываться с путями SOLIB (ленивое решение).

В качестве альтернативы, scp / ftp новый libc (тот, который вы хотите использовать, и в идеале тот, для которого у вас есть связанные символы) в /tmp и используйте LD_LIBRARY_PATH для извлечения этого (и DL_DEBUG=libs для подтверждения, если вам нужно). Используйте тот же libc для отладки

источник: я работаю в QNX, и даже мы иногда боремся с gdb libc