Здравствуйте!
Есть ли у кого-нибудь опыт настройки удаленного дебага Qt на устройстве.

конфигурация на данный момент такая

Qt Creator 2.4.1 
host        ::         Linux ubuntu-11 3.0.0-26-generic #43-Ubuntu SMP Tue Sep 25 17:20:50 UTC 2012 i686 i686 i386 GNU/Linux
target     ::         Linux dm816x-evm 2.6.37 #23 Tue Sep 25 10:32:10 MSK 2012 armv7l unknown
toolchain  ARM GNU/Linux Sourcery G++ Lite 2009q1-203

qt-everywhere-opensource-src-4.8.3

понимаю, что проблема поставлена размыто, но буду признателен за любые ссылки и советы по теме. 
и, естественно, готов ответить на дополнительные вопросы.

Конкретно с Qt -- нет. Впрочем, со всем остальным (от Borland Delphi 1.0 до связки лисп+ассэмблер  внтури микроконтроллера с 96k RAM) отладка (удалённая, приближённая, не суть) выглядела одинаково -- нахожу какой-то способ отправлять текст из программы наружу (запись в файл на диске, отправка в последовательный порт, отправка подключившэйся через TCP/IP socket программе), ставлю в программе в интересующих меня местах отладочную печать по условиям включённых опцый отладки, и печатаю интересующие меня или вообще подозрительный значения вместе с их временем.

Да, бывают некоторые исключения, когда хватает какого-то рода стандартного профиля -- например, из ltrace или gprof. Это, впрочем, редкость и и так понятно, что делать.

tzirechnoy, ты видимо не понял. Речь идет о том, как к gdbserver запущенном на ARM прицепиться с помощью критора.

да.
товарищ bsa чуть более, чем наполовину прав...

я
собрал openssh на target
собрал qt-everywhere-opensource-src-4.8.3 debug

на данный момент
соединение с устройством есть, могу запустить, остановить приложение из криэйтора.
интересует  debug.

в логе дебаггера в Creator имею
&"Error while mapping shared library sections:\n"
>&"opt/qt-embedded/lib/libQtNetwork.so.4: No such file or directory.\n"

расскажите, ЧЯДНТ. 
в gdbinit (стартовом скрипте gdb) надо что-либо прописать? 
расскажите , если не в тягость, как - где должны лежать библиотеки?

Во-первых, вопрос был сформулирован по-другому.

Во-вторых, правильный ответ на этот вопрос -- никак, не страдайте фигнёй. gdb имеет смысл для взлома чужых бинарников и разбора глюков компилятора, но QtCreator в обоих этих случаях безсмысленнен. Для отладки своих программ есть более вменяемые средства, чем пытаться по шагам угнаться за процэссором.

tzirechnoy
вообщем-то, вопрос и не был сформулирован внятно в топ посте, признаю и прошу прощения еще раз
область новая для меня и просил any help
нельзя ли поподробнее прокомментировать вот это

дабы я не страдал фигней

Да я там как раз в первом своём комменте написал, как оно обычно делается. Коротко: текстовые логи изнутри программы. Всё остальное -- от лукавого.

Да, в винде иногда кажэтся, что понажымать F8 и покликать Watches будет быстрее и проще. Это глюки -- оно на самом деле очень тяжэло и медленно, по сравнению с рассматриванием своего лога.
 
Конструкт вида  debug = fopen(...); ... if (DEBUG[feature]) { fprintf(debug, ...)  } элементарен и сильно облегчает жызнь.

tzirechnoy, я тоже так думал, пока писал программы объемом в 1-2 тетрадного листра. Когда проекты стали объемнее, то отладчик стал сильно выручать. Например, как с помощью лога отладить падение программы в неизвестном месте? Причем, программа падает где-то через час работы.
С помощью отладчика это делается легко - он перехватывает событие сбоя и ты можешь изучить стек вызовов, все переменные и пр. В случае с логами тебе надо: 1) во все функции воткнуть логирование. 2) дождаться падения и определить в какой функции. 3) добавить в эту функцию дамп всех возможных переменных. 4) дождаться падения еще раз... Итого, это может занять минимум 2 часа (это если ты код пишешь, как метеор).

Вот с помощью лога это сделать банально. Лог перед падением прервётся. Точнее, если место -- действительно трудноуловимо, то, конечно, не всё так просто -- иначе бы в core dump глянул -- сразу место и нашёл. Да, это, кстати, довольно логичное применение gdb, и иногда полезное (особенно для чужых проектов), но это отнюдь не  пошаговая отладка. И интэграцыя в среду для трёх редко используемых команд как-то не очень нужна.

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

А вот что и как Вы собираетесь в течение часа смотреть отладчиком, яростно имитируя процэссор при помощи кнопок F7 и F8 и разглядывая окошко Watches -- это, как раз, очень интересный вопрос. А уж если падает при работе заказчика с программой -- то ещё и технически очень весёлый.

мне кажется начинается небольшой отладочный холиварчик ...
вот тут тут например 


вообщем во многом согласен, то есть согласен и с tzirechnoy 
но вот, внезапно, хочется иметь коллегам удаленный дебаг на арм....

И почему-то именно в QtCreator. Передайте, что это несложно -- но глупо и вообще за такие вещи ужэ бьют по рукам.

McMan, какого года цитата?

подозреваю, 1999го

не хочу обсуждать парадигмы отладки. 
у кого нибудь есть ссылка на простейший мануал?

Да пожалуйста.  http://doc.qt.digia.com/qtcreator/creator-debugging.html  http://sourceware.org/gdb/onlinedocs/gdb/R...-Debugging.html