Отладчик, поставляемый с FreeBSD, называется gdb (GNU debugger). Он запускается по команде
% gdb progname
хотя большинство предпочитает запускать его из Emacs. Вы можете сделать это так:
M-x gdb RET progname RET
Использование отладчика позволяет вам запустить программу в более контролируемом окружении. Как правило, вы сможете выполнить программу в пошаговом режиме построчно, изучать значения переменных, изменять их, указывать отладчику выполнять программу до определенного места и затем остановиться, и так далее. Вы даже можете подключиться к уже работающей программе или загрузить файл дампа для изучения причины ошибки в программе. Возмлжно даже отладить ядро, хотя это делается немножко хитрее, чем отладка пользовательских приложений, которым посвящен этот раздел.
В gdb имеется достаточно хорошая встроенная система помощи, а также набор info-страниц, так что в этом разделе упор будет делаться на несколько основных команд.
Наконец, если вы находите, что его выдача команд в стиле командной строки в текстовом режиме неудобна, то в Коллекции Портов для него имеется графический инструмент xxgdb.
Этот раздел предназначен быть введением в использование gdb и не покрывает специальные вопросы, такие, как отладка ядра.
Чтобы получить максимумальный результат от использования gdb, вам нужно откомпилировать программу с параметром -g. Отладчик будет работать и без этой опции, но вы сможете увидеть только название текущей функции, но не ее исходный код. Если вы увидите такое сообщение:
... (no debugging symbols found) ...
при запуске gdb, то определите, что программа не была откомпилирована с опцией -g.
В приглашении gdb наберите команду break main. Это укажет отладчику пропустить предварительный подготовительный код программы и начать сразу с вашего кода. Теперь выдайте команду run для запуска программы--она начнет выполняться с подготовительного кода и затем будет остановлена отладчиком при вызове main(). (Если вы когла-либо удивлялись, откуда вызывается main(), то теперь вы должны знать!).
Теперь вы можете выполнить программу построчно по шагам, нажимая n. Если вы попали на вызов функции, то можете перейти в нее, нажав s. Оказавшись в вызове функции, вы можете вернуться из пошагового выполнения функции нажатием f. Вы можете также использовать команды up и down для просмотра вызывающей подпрограммы.
Вот простой пример того, как выявить ошибку в программе при помощи gdb. Это наша программа (с намеренно допущенной ошибкой):
#include <stdio.h>
int bazz(int anint);
main() {
int i;
printf("This is my program\n");
bazz(i);
return 0;
}
int bazz(int anint) {
printf("You gave me %d\n", anint);
return anint;
}
Эта программа устанавливает значение переменной i равным 5 и передает ее в функцию bazz(), которая выводит переданное нами число.
При компиляции и запуске программы мы получили
% cc -g -o temp temp.c
% ./temp
This is my program
anint = 4231
Это не то, что мы ожидали! Самое время посмотреть, что же происходит!
% gdb temp
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc.
(gdb) break main Пропуск начального кода
Breakpoint 1 at 0x160f: file temp.c, line 9. gdb устанавливает точку останова в main()
(gdb) run Запуск до вызова main()
Starting program: /home/james/tmp/temp Программа начинает работать
Breakpoint 1, main () at temp.c:9 gdb останавливается в main()
(gdb) n Переход к следующей строке
This is my program Программа выводит
(gdb) s Переход в bazz()
bazz (anint=4231) at temp.c:17 gdb выводит стек вызовов
(gdb)
Минуточку! Как параметр anint оказался равным 4231? Разве мы не присвоили ему значение 5 в функции main()? Давайте перейдем к функции main() и взглянем туда.
(gdb) up Переход вверх по стеку вызовов
#1 0x1625 in main () at temp.c:11 gdb выводит стек вызовов
(gdb) p i Вывод значения переменной i
$1 = 4231 gdb выводит 4231
О боже! Судя по коду, мы забыли инициализировать переменную i. Вы хотели сделать вот что
...
main() {
int i;
i = 5;
printf("This is my program\n");
...
но забыли про строку i=5;. Так как мы не присвоили начальное значение для i, то переменная принимает случайное значение, оказывающее в соответствующей области памяти при работе программы, и в нашем случае это оказалось число 4231.
Note: gdb выводит стек вызовов всякий раз, когда мы вызываем или возвращаемся из функции, даже если мы используем команды up и down для продвижения по стеку. При этом выводится имя функции и значения ее оргументов, что помогает нам отслеживать, где мы находимся и что происходит. (Стек является областью, где программа сохраняет информацию о передаваемых функциям аргументах и о том, куда нужно перейти после возврата из функции).
Файл дампа, вообще говоря, является файлом, содержащим полный образ процесса в момент его сбоя. В "добрые старые времена" программисты выводили шестнадцатиричные распечатки файлов дампа и корпели над справочниками по машинным кодам, но сейчас жизнь несколько облегчилась. В частности, во FreeBSD и других системах на основе 4.4BSD файлы дампа называются progname.core, а не просто core, для того, чтобы было понятнее, к какой программе относится соответствующий файл дампа.
Для исследования файла дампа запустите gdb обычным образом. Вместо того, чтобы выдавать команду break или run, наберите
(gdb) core progname.core
Если вы не в том же каталоге, что и файл дампа, то вам нужно сначала выполнить команду dir /path/to/core/file.
Вы должны увидеть нечто вроде следующего:
% gdb a.out
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc.
(gdb) core a.out.core
Core was generated by `a.out'.
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x7020796d.
#0 0x164a in bazz (anint=0x5) at temp.c:17
(gdb)
В этом случае программа называлась a.out, так что файл дампа называется a.out.core. Мы можем видеть, что программа завершилась аварийно из-за попытки доступа к области памяти, ей недоступной, в функции bazz.
Иногда бывает полезно иметь возможность просмотреть, как функция была вызвана, потому что в сложной программе проблема могла появиться в любом месте большого стека вызовов. Команда bt заставляет gdb выдать обратную трассировку стека вызовов:
(gdb) bt
#0 0x164a in bazz (anint=0x5) at temp.c:17
#1 0xefbfd888 in end ()
#2 0x162c in main () at temp.c:11
(gdb)
При сбое программы была вызвана функция end(); в этом случае функция bazz() была вызвана из main().
Одной из выдающихся особенностей gdb является то, что он может подключаться к программе, которая уже выполняется. Конечно, при этом предполагается, что у вас достаточно полномочий, чтобы это осуществить. Имеется проблема в ситуации, когда вы хотите выполнить трассировку порождаемого процесса, но отладчик позволяет вам трассировать только родительский.
В этой ситуации нужно запуститть еще один отладчик gdb, воспользоваться командой ps для поиска идентификатора порожденного процесса и выполнить команду
(gdb) attach pid
в gdb, после чего отлаживать программу обычным образом.
"Это все хорошо", думаете, наверное, вы, "но к моменту, когда я все это сделаю, порожденный процесс уже завершит свою работу". Может быть, и нет, дорогой читатель, и вот как это делается (согласно info-страницам программы gdb):
...
if ((pid = fork()) < 0) /* _Always_ check this */
error();
else if (pid == 0) { /* child */
int PauseMode = 1;
while (PauseMode)
sleep(10); /* Wait until someone attaches to us */
...
} else { /* parent */
...
Теперь все, что вам нужно сделать, это подключиться к порожденному процессу, установить значение переменной PauseMode в 0 и дождаться возврата из вызова функции sleep()!