Некоторые полезные штуки облегчающие жизнь при разработке программ.

Синтаксические ошибки, которые скрывают от нас макроопределения.

Иной раз трудо бывает отловить ошибки допущенные в определении макросов препроцессора. Попробуйте:

На выходе получим наш "<исходник>" обработанный препроцессором с развернутыми в нем всеми макрами из хедеров найденных по стандартным путям и хедеров из "<там где искать наши хедеры>". Задача поиска блох упростится.

Где GDB находит исходники?

Когда GDB'е требуются исходники, он ищет их вначале в своем внутреннем списке директорий исходников (source path), затем, в случае неудачи, пробует директорию компиляции (если в нем есть соответствующая запись). Последней возможностью является текущая рабочая директория GDB. Следующие команды позволяют манипулировать списком директорий исходников:

• directory DIRNAME ... (или dir DIRNAME ...) - добавляет новую директорию в начало списка, если данная директория уже присутствует, она сдвигается в начало. При добавлении нескольких директорий разделителем является двоеточие;
• directory - опустошает список;
• show directories - выводит весь список.

Изучение процессов с имеющимися в них fork'ами

При изучении поведения таких процессов сталкиваемся с той проблемой, что отладчик после выполнения fork продолжает отлаживать родительский процесс. Специальных средств для обхода такой ситуации не нашлось. Однако, в мане можно найти такой совет:

Допустим, имеем процесс aaa, который посредством fork делится на родительский и дочерний. Находим в исходнике программы точку ветвления и вставляем в тело дочернего кода sleep(). Компилируемом. Теперь, после прохождении точки ветвления дочерний процесс засыпает, и у нас есть время выполнить команду ps и таким образом определить его PID (пусть он оказался 1234) и, за тем, говорим в среде gdb:

(gdb) attach 1234

Ву-аля! Мы перецепились к дочернему процесс, и можем теперь отлаживать его на здоровье!