Цель с символами отладки
Это самый простой способ начать работу, и он особенно полезен при разработке одной конкретной общей библиотеки.
Сначала скопируйте исполняемый файл теста и совместно используемую библиотеку в целевую с отладочной информацией:
Затем на цель:
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 это самое надежное.
Target gdbserver 7.12-6, хост arm-linux-gnueabihf-gdb 7.6.1 от Linaro.
Целевые библиотеки без символов отладки
Распространение целевых библиотек перед развертыванием на встроенных целях является обычным явлением, поскольку отладочная информация делает их способными больше.
Например, 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 ищет общие библиотеки в целевом корне / по умолчанию.