Предыстория
На данный момент добился успешной компиляции C/C++ проекта на базе Eclipse IDE и запуска получаемого бинарника (.elf) на плате. Но при этом все что я могу - это откомпилить проект на хосте, скопировать по TFTP на плату (target) и запустить. Никакой отладки пока нет, но дальше без нее - никак.
Поэтому возникла задача:
иметь пошаговую отладку своего приложения на плате.
Как я понял, для этого можно использовать ethernet (TCP/IP) соединение между хостом и платой. В качестве софта который осуществляет отладку используется gdb: gdbserver на плате (target) и gdb на хосте.
На хосте вроде бы все настроил, об этом отписался в соседней ветке: http://starterkit.ru/html/index.php?name=forum&op=view&id=7832&num=2#14739
ВНИМАНИЕ, ВОПРОС:
Как запустить gdbserver на плате?
Если просто тупо скопировать, то он не запускается, выдает ошибку:
Копирование указанной библиотеки в папку с gdbserver не помогает, все равно та же ошибка.
Правильно я понимаю, что надо gdbserver включить в состав файловой системы buildroot?
Смотрите например в google по ключевой фразе "eclipse linux remote debugging ssh"
Скопируйте в /lib на целевой платформе или еще лучше все библиотеки туда вручную скопируйте, например у CS они тут
Path_to_CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/libc/lib
потому что при утановке в buildroot они все проходят через srtip который удаляет всю отладочную информацию.
1. gdbserver на target-е запустился успешно.
При старте отладки gdbserver выдает "Remote debugging from host ..."
т.е. обмен идет нормально.
Но при этом в Eclipse при старте отладки выдает no source available for "0x0".
1. спасибо sasamy за правильные ключевые слова гугла, нашел очень наглядную статейку с инструкциями, как настроить eclipse в линуксе для remote debugging: http://embedded-linux.co.uk/tutorial/eclipse-rse
2. согласно указанной инструкции полностью заработал RSE (Remote System Explorer), благодаря которому отладка полностью автоматизируется:
- не нужно вручную копировать бинарник на target, Eclipse делает это автоматически;
- автоматом запускается gdbserver;
- ну и как бонус возможность копировать файлы с host на target и обратно через интерфейс эклипса.
2.1. чтобы наладить RSE пришлось сделать следующее:
- установить sftp-server на target (включаем dropbear и openssh в buildroot-е)
- создать пользователя и дать ему права (chmod 666) для /dev/null, иначе sftp не работает. можно и под рутом работать с sftp, но для этого надо установить руту пароль (с пустым паролем не работает) и вообще под рутом вроде как не рекомендуют.
3. Теперь по CTRL+F11 (Run) программа успешно стартует, выполняется и результат выполнения видно в консоли эклипса, что удобно т.к. не нужно переключаться на консоль target-а и смотреть туда.
4. Однако отладка (по F11, Debug) пока что не завелась.
т.е. поддерживает CodeSourcery который как раз таки линуховый кросс-компилятор.
2. Другой вопрос зачем вообще ставить этот плагин - я честно говоря уже не помню, что именно он дает, но в какой-то доке вычитывал набор который надо ставить и туда входил этот GNU ARM.
там просто при создании проекта выбираешь что это кросскомпиляция будет, указываешь префикс, путь до бинарников и еклипс сам подставляет префиксы - ничего больше ему не нужно менять и RSE там уже интегрирован - ничего больше скачивать и доустанавливать ненужно. Только у меня другая проблема с этим еклипсом - он зависает при загрузке файла на таргет, судя по всему не может добавить права на исполнение - сам файл заливается.
Причем тоже самое с другой версией совершенно (которая в убунте штатная).
Интересно что сам ssh на плате прекрасно работает - я недавно как раз с Qt Creator подобные эксперименты проводил и там все ок..
1. По поводу "Error during file upload.":
иногда (очень редко) наблюдал у себя такие же сообщения. лечилось так:
- переходим в RSE;
- делаем коннект (коннектится ОК);
- делаем дисконнект.
После этого запускаем отладку через RSE - ошибка пропадает.
2. Избавился от warning-ов gdb.
Для этого:
a)
в debug configurations прописываем пути к либам компилятора
/arm-2007q1/arm-none-linux-gnueabi/lib
/arm-2007q1/arm-none-linux-gnueabi/libc/lib
как на скриншоте: http://img843.imageshack.us/img843/5850/screenshotdebugconfigur.png
b) создаем в папке эклипс проекта файл .gdbinit и прописываем там:
set sysroot <здесь_ваш_путь>/arm-2007q1/arm-none-linux-gnueabi/
В итоге варнинги пропадают, но отладка все равно не идет.
Теперь имеем другой Suspended:
Короче источник бед локализован - это breakpoint-ы.
Если убрать галочку на "Stop on startup at: main" в Debug configurations и убрать все брейкпоинты то отладка идет нормально, на паузу реагирует нормально и доступен просмотр всех текущих переменных.
Как только появляется хотя бы один брейкпоинт, то после него при продолжении отладки (resume, stop over или др.) - все отваливается.
Собрал систему на ядре 3.1.5, buildroot 2012.0110 (snapshot).
Результат тот же - при появлении любого брейкпоинта отладка отваливается. Без брейкпоинтов все работает норм.
Сегодня коллективный мозг сгенерил такую идею для обхода этой проблемы.
===============================================
Делаем макрос:
Объявляем глобальную переменную
Теперь в любом месте программы где нас интересует отладка вставляем BREAKPOINT.
Когда в консоли видим надпись breakpointed, то неспешно нажимаем паузу и вуаля - мы в отладке в нужном месте.
Чтобы продолжить выполнение изменяем значение переменной breakpoint на 0 и жмем F8 (Resume). Прога продолжает работать и отладка не отваливается.
Выглядит это так: http://img600.imageshack.us/img600/272/screenshot11d.png
НЕДОСТАТОК:
1. вместо нормальных брейкпоинтов мы правим код, вставляя строчки с зацикливанием. соответственно находу вставить какой либо брейкпоинт нельзя.
2. по-прежнему нам недоступно выполнение по шагам типа Step into, Step over.