Отладка разделяемых библиотек с помощью gdbserver

Question

Я использую gdbserver для целевой и CodeSourcery IDE. Мое оборудование - это gumstix с omap3530.

Я могу выполнить код в своем основном приложении, но если я попытаюсь войти в функцию в общей библиотеке, я получаю адрес памяти, и отладчик завершается.

Это моя библиотека, которая компилируется и копируется в папку Lib/на целевой системе. (В нем есть символы отладки) я попытался использовать файл .gbdinit установить solib-абсолютный префикс/Библиотека

Вот предупреждение от GdB следа:

903,056 13-gdb-set sysroot-on-target /lib 
903,065 13^done 
903,065 (gdb) 
903,065 14-target-select remote 192.168.1.101:2345 
903,114 =thread-group-started,id="i1",pid="42000" 
903,114 =thread-created,id="1",group-id="i1" 
903,115 15-list-thread-groups --available 
903,120 16-list-thread-groups 
903,128 &"warning: Unable to find dynamic linker breakpoint function.\nGDB will be unable to debug shared library initializers\nand track explicitly loaded dynamic code." 
903,128 &"\n" 

что приводит к

903,395 &"Error while mapping shared library sections:\n" 
903,397 &"/lib/libCoreLib.so: Invalid argument.\n" 
903,399 =library-loaded,id="/lib/libCoreLib.so",target-name="/lib/libCoreLib.so",hostname="/lib/libCoreLib.so",low-address="0x0",high-address="0x0",symbols-loaded="0",thread-group="i1" 

Answer 1

Вы можете отлаживать с библиотекой, установленной на вашем хосте, при условии, что debugg машина является также машиной разработки. В этом случае вы используете set sysroot вместо set sysroot-on-target. Например:

set sysroot /home/username/.../rootfs/ 

где /home/username/.../rootfs/ содержит копию вашей целевой файловой системы

Я думаю, вы должны также указать / вместо /lib

Answer 2

Аналогичная проблема была обнаружена во время отладки. Отладка висела. Конфигурация выглядит следующим образом

Хост: Ubuntu 12.04LTS

IDE: Затмение Kepler

Цель: Beaglebone Black/ARM A8

OS: Ангстрем

Решение

библиотеки Обновление и включает в себя

Выберите свойства проекта в Eclipse,

• C/C Общие ++> Paths и символы> (включают TAB) GNU C> Добавить> Файлы системы> /> usr Изменить// usr/lib/gcc/i686-linux-gnu/4/6/включить в/usr/arm-linux-gnueabi/include

• C/C++ Общие сведения> Пути и символы> (Включить TAB) GNU C++> Добавить>
  Файловые системы> /> usr /usr/arm-linux-gnueabi/include/c++/4.6.3/рычажного линукс-gnueabi

• C/C Общие ++> Дорожки и символы> (Library Paths TAB)> Добавить> Файлы системы> /> USR/USR/арм-линукс-gnueabi/Библиотека

Answer 3

Добрый день,

Если переменная «Debug-файл-каталог» в GDB установлена ​​неправильно, то сообщаемые сообщения об ошибке содержит: предупреждения: Не удается найти динамический компоновщик точку останова функцию.

Корневая файловая система мишени находится на моем главном компьютере в /Opt/ARM-Linux-gnueabihf-корневой файловой системы

Следующие две команды помогли мне получить удаленную отладку рабочего через gdbserver с помощью GDB (v7 .11.1):

set debug-file-directory /opt/arm-linux-gnueabihf-rootfs/usr/lib/debug 
set sysroot /opt/arm-linux-gnueabihf-rootfs 

Я заметил, что если «SYSROOT» имеет косую черту в пути, затем GDB не может использовать it.You будет видеть это (неправильный выход) после подключения к удаленной цели :

Reading /lib/ld-linux-armhf.so.3 from remote target... 

или

Reading symbols from /opt/arm-linux-gnueabihf-rootfs/lib/ld-linux- 
armhf.so.3...(no debugging symbols found)...done 

вместо правильного вывода:

Reading symbols from /opt/arm-linux-gnueabihf-rootfs/lib/ld-linux- 
armhf.so.3... 
Reading symbols from /opt/arm-linux-gnueabihf-rootfs/usr/lib/debug/ 
lib/arm-linux-gnueabihf/ld-2.23.so...done. 

С уважением, Frikkie Thirion

Answer 4

Target с отладочной

Это простейший метод для работы, и он особенно полезен при разработке одной конкретной разделяемой библиотеки.

Первая копия тест исполняемый файл и разделяемые библиотеки к цели с отладочную информацию:

• чек с readelf ----debug-dump=decodedline libmyib.so: How can I tell if a library was compiled with -g?
• Я рекомендую использовать сервер NFS на хосте, так что скомпилированного получает автоматически загружается после компиляции

Тогда на цель:

gdbserver --multi :1234 ./executable_name 

Ведущий:

arm-linux-gnueabihf-gdb -q -nh \ 
    -ex "target extended-remote target-hostname-or-ip:1234" \ 
    -ex "file ./executable_name" \ 
    -ex 'tb main' \ 
    -ex 'c' \ 
    -ex 'set solib-search-path .' 

sharedlibrary libmylib.so также работает.

Проблема была в том, что gdbserver останавливается у динамического загрузчика, до main, а динамические библиотеки еще не загружены в этот момент, и поэтому GDB не знает, куда еще будут отображаться символы.

У GDB есть механизмы, позволяющие автоматически загружать общие библиотечные символы, а если я компилирую для хоста и выполняю локальную работу gdbserver, то работать с main не требуется. Но на цели ARM это самая надежная вещь.

Целевая задача gdbserver 7.12-6, принимающая сторона arm-linux-gnueabihf-gdb 7.6.1 из Линаро.

Целевых библиотеки без отладочных символов

Распространено раздеться целевыми библиотеками перед развертыванием на встроенных целях, так как отладочная информация делает их пути больше.

Например, Buildroot делает это по умолчанию, но вы можете отключить его с помощью BR2_STRIP_none=y.

Вы можете определить этот сценарий, выполнив:

info shared 

Это показывает, что-то вроде:

From    To     Syms Read Shared Object Library 
0x00007ffff7df7f90 0x00007ffff7dfcdd7 Yes (*)  target:/lib/ld64-uClibc.so.0 
0x00007ffff7b3a9b0 0x00007ffff7bbe05d Yes (*)  target:/lib/libc.so.0 
(*): Shared library is missing debugging information. 

так есть звездочки (*) для обеих библиотек, говорит, что отладочная информация отсутствует ,

Если это так, то вы должны сообщить GDB об использовании разделяемых библиотек на хосте до.

Buildroot, например, делает это легко для нас, так как он поддерживает staging каталог, который содержит общие библиотеки, прежде чем они были раздеты и в те же относительные пути, как в мишени:

set sysroot buildroot/output/staging/ 

Когда эта опция набор, gdb немедленно ищет библиотеки в хосте вместо мишени, и находит /lib/libc.so.0 на пути buildroot/output/staging/ + /lib/libc.so.0:

Reading symbols from buildroot/output/staging/lib/ld64-uClibc.so.0...done. 
Reading symbols from buildroot/output/staging/lib/libc.so.0...done. 

TODO: Я не думаю, что вы можете установить более одного sysroot, поэтому все ваши общие библиотеки должны быть размещены в их правильных относительных путях, как в целевом изображении.

Если вы отметите плохой SYSROOT по умолчанию, вы увидите:

show sysroot 

отдавания:

target: 

означает, что gdb поиск общих библиотек на целевом корне / по умолчанию.