Почему gdbserver не найден при использовании внешнего набора инструментов Linaro в Buildroot? - PullRequest
Новая
       81

Почему gdbserver не найден при использовании внешнего набора инструментов Linaro в Buildroot?

0 голосов
/ 02 января 2019

Я использую Buildroot 2018.02 для платы IMX6 и внешнего слишком цепочки Linaro 2017.11 на основе GCC 2017.11 (GCC 7.2.1)

Теперь я добавляю некоторые средства отладки, такие как gdbserver, на цель.

Все в порядке, если я использую опцию "Build cross gdb for the host" и выбираю версию отладчика gdb 7.11.x для хоста вместе с gdbserver (BR2_PACKAGE_GDB_SERVER) в меню "Target Packages > Debugging,..".В Buildroot также доступны другие версии gdb, такие как 7.12.x и 8.0.x.

Однако для внешнего набора инструментов рекомендуется: https://github.com/mbats/eclipse-buildroot-bundle/wiki/Tutorial-:-How-to-debug-a-remote-application-%3F, что означает активацию только *Опция 1012 * в Buildroot (хотя пост немного устарел)

Я заметил, что в описании BR2_TOOLCHAIN_EXTERNAL_LINARO_ARM написано, что Linaro gdb основан на gdb 8.0, поэтому более новая версия, чем та, которую я использую (7.11.x).

Но когда я это делаю, на целевой плате появляется следующее сообщение: 

# gdbserver
-sh: gdbserver: not found

, несмотря на следующее: 

# which gdbserver
/usr/bin/gdbserver

gdbserver binaryнаходится на цели.

Как это исправить в Buildroot?

Более того, у меня есть два дополнительных вопроса:

  1. Действительно ли важно иметь набор инструментов Linaro gdbвместо gdb 7.11.x, который работает "из коробки" в моем случае?
  2. Если я не использую Linaro GDB, тогда я должен использовать версию GDB 8.0.x (потому что версия Linaroна основе 8.0 ГБД)?

Спасибоза вашу помощь.

Ответы [ 2 ]

0 голосов
/ 03 января 2019

Двоичный файл gdbserver в наборе инструментов Linaro 2017.11 не работает: он запрашивает /usr/lib/ld.so.1 в качестве интерпретатора программы (см. Ниже), но этот интерпретатор программы не существует.

Вы можете попытаться создать символическую ссылку /usr/lib/ld.so.1 -> /lib/ld-linux-armhf.so.3 (добавьте ее в оверлей вашей файловой системы, если он работает). Кроме того, вы можете явно указать интерпретатор программы, поместив его перед исполняемым файлом, то есть /lib/ld-linux-armhf.so.3 /usr/bin/gdbserver.

«Интерпретатор программы» - это параметр файла ELF, который указывает на программу, которая используется для загрузки файла ELF в память и начала его выполнения. Основная обязанность интерпретатора программы - найти и загрузить динамические библиотеки, необходимые программе. Таким образом, его обычно называют «загрузчиком динамической библиотеки», или ld.so. Он создается и устанавливается вместе с набором инструментов, в частности, стандартной библиотекой Си (glibc). Когда программа связана, компоновщик также устанавливает интерпретатор программы (он копируется из libc.so). Очевидно, Линаро сделал нечто действительно странное, чтобы в результате получить неверный программный интерпретатор в исполняемом файле gdbserver.

0 голосов
/ 03 января 2019

# gdbserver
-sh: gdbserver: not found

depsite следующее:

# which gdbserver
/usr/bin/gdbserver

Скорее всего:

  1. gdbserver - это динамически связанный двоичный файл, а
  2. Интерпретатор ELF , с которым связан этот двоичный файл, отсутствует в целевой системе.

Используйте readelf -l /usr/bin/gdbserver | grep -i interpreter, чтобы узнать, какой загрузчик времени выполнения этого gdbserver требует. Убедитесь, что этот файл отсутствует на цели. Скопируйте его в цель и наслаждайтесь.

...