Как вы используете GDB для отладки кода?

В общем, вы находите то, что не так, как должно быть, и работаете в обратном направлении, пока не поймете, почему.

Самый очевидный - самый полезный: установка точки останова на функции или номере строки и переход по коду строка за строкой.

Еще один полезный совет - иметь функции show для всех ваших структур / объектов, даже если они никогда не используются в вашей программе, потому что вы можете запускать эти функции из gdb:

gdb> p show_my_struct(struct)

My custom display of Foo:
   ...

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

gdb> watch foo
Watchpoint4: foo
gdb>

Некоторые подсказки:

• используйте графический интерфейс (kdbg неплох, ddd, по крайней мере, лучше, чем gdb из командной строки, kdevelop имеет хороший интерфейс gdb, но имеет некоторые bgs, nemiver тоже выглядит неплохо, но все еще в разработке)
• убедитесь, что у вас есть отладочные символы и исходный код для всех важных частей (ваш собственный код, а также некоторые системные библиотеки)
  • в RedHat вы можете установить пакеты -debuginfo, чтобы символы и исходный код волшебным образом появлялись в отладчике - действительно здорово, потому что вы можете просматривать вызовы функций libc и т. д.
  • в Debian / Ubuntu вы можете установить пакеты -dbg для получения символов; установка соответствующих исходных файлов для системных пакетов кажется сложной, хотя
• Я обычно добавляю вызовы assert () и abort () в местах, которые не должны быть доступны, или в местах, которые я хочу изучить (какая-то тяжелая точка останова)
• в идеале вызовы assert () или abort () должны быть заключены в какой-либо метод или макрос, который разрешает их только в выпусках отладки, или, что еще лучше, включает их только в том случае, если установлена ​​определенная переменная env
• установить обработчик сигналов для SIGSEGV и SIGABRT; лично я проверяю, установлен ли определенный env var перед установкой обработчиков; и в обработчике я выполняю жестко запрограммированную внешнюю команду, которая обычно находится где-то в ~ / .local / bin /; эта команда может затем запустить kdbg и присоединить его к аварийному приложению. Вуаля, отладчик появляется в тот момент, когда ваше приложение делает что-то плохое.
• Если вы используете модульные тесты, вы можете аналогичным образом подключить отладчик, когда тестовый пример не выполняется, чтобы затем проверить приложение.

Используйте ddd, визуальный интерфейс для gdb. Это позволяет вам легко делать что-то с помощью нескольких щелчков мыши и визуализировать, как работает код, плюс в консоли отладчика у вас есть интерактивный gdb.

Вы также можете использовать Geany.

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

Чтобы проверить аварийный дамп (или файл ядра, как его чаще называют), запустите GDB следующим образом:

gdb <program-name> <core-file>

Например:

gdb a.out core

После запуска этой команды в основном файле gdb сообщит вам, как программа завершилась, и покажет, где в программе произошла ошибка:

Program terminated with signal 11, Segmentation fault.
#0  0x08048364 in foo () at foo.c:4
4         *x = 100;

В приведенном выше примере вы можете видеть, что программа завершилась из-за ошибки сегментации при попытке присвоить значение указателю. Набрав backtrace (или bt или where) в приглашении GDB, вы можете просмотреть полную трассировку программы:

(gdb) backtrace
#0  0x08048364 in foo () at foo.c:4
#1  0x0804837f in main () at foo.c:9

На этом этапе вы знаете, что main() с именем foo() и foo() потерпели крах в строке 4 при попытке присвоить значение *x. Часто это дает достаточно информации, чтобы вы могли исправить ошибку.

Я много занимаюсь разработкой параллельных программ, поэтому я обнаружил, что использование простой оболочки в python / ruby, которая позволяет мне прикреплять gdb ко всем процессам на всех узлах, и обратная связь со мной чрезвычайно полезно (я не нашел лучший способ, если кто-нибудь знает о нем, хотя, чтобы не перехватывать нить ...)

Я не уверен, насколько опытен OP, поэтому:

Документация GDB довольно приятная и всеобъемлющая. Первая глава - хорошее введение во все основы.

http://www.gnu.org/software/gdb/documentation/

Хотя это и не GDB, они связаны: Я лично обнаружил, что разбиение сложных строк на части помогает определить, какие утверждения ошибочны.

Кроме того, Valgrind (http://valgrind.org/) действительно хорош / полезен для решения проблемы переполнения буфера и тому подобного (мне не повезло с GDB для этого.

Базовый, но очень полезный - используйте текстовый интерфейс с опцией -tui.