2009-12-01 6 views
5

Я разрабатываю приложение, которое работает на небольшом Linux-сервере SBC (~ 32 МБ ОЗУ). К сожалению, мое приложение недавно стало слишком большим, чтобы работать под GDB. Кто-нибудь знает какие-либо хорошие, легкие методы отладки, которые я могу использовать во встроенной Linux? Даже возможность просмотра трассировки стека потока будет чрезвычайно полезна.Легкая отладка на встроенной Linux

Следует отметить, что это приложение написано на C++ и запускает несколько потоков, поэтому gdbserver не работает, поскольку он не работает с многопоточными приложениями.

Спасибо заранее,

Maha

+1

Вы уверены, что gdbserver не работает для многопоточных приложений? На этой странице это работает: http://www.kegel.com/linux/gdbserver.html. –

ответ

4

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

info threads 

Содержит список всех потоков в системе

thread <thread number from info threads> 

переключается на этот поток исполнения.

thread apply XXX <command> 

Выполняется по резьбе, обозначенной XXX, которая также может быть «все». Так что если вы хотите, чтобы задний след от всех запущенных потоков сделать

thread apply all bt 

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

+0

Вам нужно запустить gdb/gdbserver со специальными аргументами? Я работаю на процессоре ARM. Когда я запускаю «gdbserver localhost: 12345 myapp», а затем запускаю ту же версию gdb на моем хосте и вводим команду «target remote 10.0.150.92:12345», отладчик запутывается, поскольку он думает, что работает только один поток (перерывы с каждый контекстный переключатель и «информационные потоки» отчитываются только за 1 рабочий поток). – Maha

+0

Мне не нужно запускать специальные аргументы при отладке, наш проект также находится в ARM. Мой процесс для отладки удаленно звучит так же, как ваш. На цели: gdbserver локальный: 10000 MyApp На хосте: arm_v5t-ле-GDB MyApp В командной строке хост GdB: целевой удаленный : По одной версии БГД вы имеете в виду рука строить правильно? Есть ли причина, по которой ваше приложение будет получать сигналы, такие как SIGUSR1/2 или что-то во время переключения контекста? Это заставит отладчик остановиться. Приложение как для цели, так и для хоста должно быть построено с помощью символов отладки, а NFS - для этого хоста. – asm

+0

Мой хост-компьютер - это система x86, а целевая система запускает процессор ARM. Ваш хост также является системой ARM? Если нет, возможно, я пропустил что-то в своей сборке GDB (я построил GDB 7.0 для ARM, а затем построил его отдельно для x86). Мое приложение явно не генерирует SIGUSR1/2 - я проверял, что он разбивается на коммутаторы контекста, поскольку отладчик думает, что работает только один поток. – Maha

2

Я слышал от людей, делающих хаков, как запустить приложение в эмуляторе, как QEMU и затем запустить GDB (или вещи, как Valgrind) на этом. Это звучит болезненно, но если это сработает ...

Не могли бы вы получить где-нибудь с libunwind (чтобы получить трассировки стека) и в режиме ввода в формате printf?

+0

Спасибо за указатели.Я смотрел, как работает под эмулятором, но это определенно болезненный способ пойти и, вероятно, съел бы больше времени, чем я могу потратить. Я делаю запись в формате printf прямо сейчас, но это довольно сложное приложение, и иногда сложно определить, какой именно компонент вызывает проблему в первую очередь. Libunwind определенно выглядит полезным инструментом, я дам ему шанс. – Maha

1

печати Последовательный порт является наиболее легкий я могу думать ~~~ Легко видеть в Хосте, и простой и легкий вес код внутри приложения

~~

Если у вас нет последовательного порта , как только мы использовали порт GPIO и имитировали последовательный порт, используя его. Он работал отлично, но был немного медленным :-(~~~

0

Есть ли причина, по которой вы создали свой собственный отладчик? Я разрабатываю систему Linux с использованием ARM-процессора (AT91SAM926x), и мы используем как компилятор, так и отладчик из CodeSourcery. Я не думаю, что они выпустили версию с GDB 7, но я отлаживаю многопоточные приложения на C++ с помощью инструмента gdbserver без каких-либо проблем.

+0

Мы используем инструментальную цепочку, поставляемую нашим производителем SBC. К сожалению, они не поставляют готовый GDB, поэтому я сам. – Maha

+2

Одна вещь, которую вы могли бы попробовать, - создать более старую версию GDB. GDB 7 является очень новым, и я прочитал несколько сообщений об основных ошибках (но не связанных с ARM). Мы запускаем версию 6.7. –

0

Gdbserver действительно работает с многопоточными приложениями. Однако вам нужно скомпилировать кросс-целевой отладчик для вашего хоста, чтобы он работал с вашим целевым gdb.

Смотрите эту статью для детального описания того, как это сделать:

Remote cross-target debugging with GDB and GDBserver

+0

Спасибо за ссылку. Я следовал инструкциям, но они не работали для меня. Попытка построить двоичные файлы с ручным управлением с его методом не удалась - сделать умирает, жалуясь, что компилятор C не может сгенерировать исполняемые файлы. Я не знаю, почему это происходит, поскольку процесс сборки GDB обычно достаточно умный, чтобы не тестировать исполняемые файлы, которые он генерирует при кросс-компиляции. – Maha

Смежные вопросы