Отладка с помощью GDB. Основы использования отладчика WinDbg Возобновление выполнения, пошаговая отладка

GNU Debugger – переносимый отладчик проекта GNU, который работает на многих UNIX-подобных системах и умеет производить отладку многих языков программирования, включая Си, C++, Ada и Фортран. GNU Debugger – свободное программное обеспечение, распространяемое по лицензии GNU General Public License.

Первоначально GNU Debugger написан Ричардом Столлманом в 1988 году. За основу был взят отладчик DBX, поставлявшийся с дистрибутивом BSD. С 1990 до 1993 гг. проект поддерживался Джоном Джилмором, во время его работы в компании Cygnus Solutions. В настоящее время разработка координируется Управляющим комитетом GDB (GDB Steering Committee), назначенным Free Software Foundation.

Технические детали GNU Debugger

Особенности

GNU Debugger предлагает обширные средства для слежения и контроля за выполнением компьютерных программ. Пользователь может изменять внутренние переменные программ и даже вызывать функции независимо от обычного поведения программы. GNU Debugger может отлаживать исполняемые файлы в формате a.out, COFF (в том числе исполняемые файлы Windows), ECOFF, XCOFF, ELF, SOM, использовать отладочную информацию в форматах stabs, COFF, ECOFF, DWARF, DWARF2. Наибольшие возможности отладки предоставляет формат DWARF2.

GNU Debugger активно развивается. Например, в версии 7.0 добавлена поддержка «обратимой отладки», позволяющей отмотать назад процесс выполнения, чтобы посмотреть, что произошло. Также в версии 7.0 была добавлена поддержка скриптинга на .

Для работы с GNU Debugger были созданы и другие инструменты отладки например, датчики утечки памяти.

Мультиплатформенность и поддержка встроенных систем

GNU Debugger может быть скомпилирован для поддержки приложений для нескольких целевых платформ и переключаться между ними во время отладочной сессии. Процессоры, поддерживаемые GNU Debugger (2003): Alpha, ARM, H8/300, System/370, System/390, x86 и x86-64, IA-64 (Itanium), Motorola 68000, MIPS, PA-RISC, PowerPC, SuperH, SPARC, VAX, A29K, ARC, AVR, CRIS, D10V, D30V, FR-30, FR-V, Intel i960, M32R, 68HC11, Motorola 88000, MCORE, MN10200, MN10300, NS32K, Stormy16, V850 и Z8000. (Более новые выпуски не будут, вероятно, поддерживать некоторых из них.) Целевые платформы, на которых GNU Debugger не может быть запущен, в частности, встроенные системы, могут поддерживаться с помощью встроенного симулятора (процессоры ARM, AVR), либо приложения для них могут быть скомпилированы со специальными подпрограммами, обеспечивающими удалённую отладку под управлением GNU Debugger, запущенном на компьютере разработчика. Входным файлом для отладки, как правило, используется не прошиваемый двоичный файл, а файл в одном из поддерживающих отладочную информацию форматов, в первую очередь ELF, из которого впоследствии с помощью специальных утилит извлекается двоичный код для прошивки.

Удалённая отладка

При удалённой отладке GNU Debugger запускается на одной машине, а отлаживаемая программа запускается на другой. Связь осуществляется по специальному протоколу через последовательный порт или TCP/IP. Протокол взаимодействия с отладчиком специфичен для GNU Debugger, но исходные коды необходимых подпрограмм включены в архив отладчика. Как альтернатива, на целевой платформе может быть запущена использующая тот же протокол программа gdbserver из состава пакета GNU Debugger, исполняющая низкоуровневые функции вроде установки точек останова и доступа к регистрам и памяти.

Этот же режим используется для взаимодействия со встроенным отладчиком ядра Linux KGDB. С его помощью разработчик может отлаживать ядро как обычную программу: устанавливать точки останова, делать пошаговое исполнение кода, просматривать переменные. Встроенный отладчик требует наличия двух машин, соединенных через Ethernet или последовательный кабель, на одном из которых запущен GNU Debugger, на другом – отлаживаемое ядро.

Пользовательский интерфейс

В соответствии с идеологией ведущих разработчиков Free Software Foundation, GNU Debugger вместо собственного графического пользовательского интерфейса предоставляет возможность подключения к внешним IDE, управляющим графическим оболочкам либо использовать стандартный консольный текстовый интерфейс. Для сопряжения с внешними программами можно использовать язык текстовой строки (как это было сделано в первых версиях оболочки DDD), текстовый язык управления gdb/mi, либо интерфейс для языка .

Были созданы такие интерфейсы как DDD, cgdb, GDBtk/Insight и «GUD mode» в . С GNU Debugger могут взаимодействовать такие IDE, как

Перевод статьи Аллана О’Доннелла Learning C with GDB .

Исходя из особенностей таких высокоуровневых языков, как Ruby, Scheme или Haskell, изучение C может быть сложной задачей. В придачу к преодолению таких низкоуровневых особенностей C, как ручное управление памятью и указатели, вы еще должны обходиться без REPL . Как только Вы привыкнете к исследовательскому программированию в REPL, иметь дело с циклом написал-скомпилировал-запустил будет для Вас небольшим разочарованием.

Недавно мне пришло в голову, что я мог бы использовать GDB как псевдо-REPL для C. Я поэкспериментировал, используя GDB как инструмент для изучения языка, а не просто для отладки, и оказалось, что это очень весело.

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

Введение в GDB

Начнем с создания следующей небольшой программы на С – minimal.c :

Int main() { int i = 1337; return 0; }
Обратите внимание, что программа не делает абсолютно ничего, и даже не имеет ни одной команды printf . Теперь окунемся в новый мир изучения С используя GBD.

Скомпилируем эту программу с флагом -g для генерирования отладочной информации, с которой будет работать GDB, и подкинем ему эту самую информацию:

$ gcc -g minimal.c -o minimal $ gdb minimal
Теперь Вы должны молниеносно оказаться в командной строке GDB. Я обещал вам REPL, так получите:

(gdb) print 1 + 2 $1 = 3
Удивительно! print – это встроенная команда GDB, которая вычисляет результат С-ного выражения. Если Вы не знаете, что именно делает какая-то команда GDB, просто воспользуйтесь помощью – наберите help name-of-the-command в командной строке GDB.

Вот Вам более интересный пример:

(gbd) print (int) 2147483648 $2 = -2147483648
Я упущу разъяснение того, почему 2147483648 == -2147483648 . Главная суть здесь в том, что даже арифметика может быть коварная в С, а GDB отлично понимает арифметику С.

Теперь давайте поставим точку останова в функции main и запустим программу:

(gdb) break main (gdb) run
Программа остановилась на третьей строчке, как раз там, где инициализируется переменная i . Интересно то, что хотя переменная пока и не проинициализирована, но мы уже сейчас можем посмотреть ее значение, используя команду print :

(gdb) print i $3 = 32767
В С значение локальной неинициализированной переменной не определено, поэтому полученный Вами результат может отличаться.

Мы можем выполнить текущую строку кода, воспользовавшись командой next :

(gdb) next (gdb) print i $4 = 1337

Исследуем память используя команду X

Переменные в С – это непрерывные блоки памяти. При этом блок каждой переменной характеризуется двумя числами:

1. Числовой адрес первого байта в блоке.
2. Размер блока в байтах. Этот размер определяется типом переменной.

Одна из отличительных особенностей языка С в том, что у Вас есть прямой доступ к блоку памяти переменной. Оператор & дает нам адрес переменной в памяти, а sizeof вычисляет размер, занимаемый переменной памяти.

Вы можете поиграть с обеими возможностями в GDB:

(gdb) print &i $5 = (int *) 0x7fff5fbff584 (gdb) print sizeof(i) $6 = 4
Говоря нормальным языком, это значит, что переменная i размещается по адресу 0x7fff5fbff5b4 и занимает в памяти 4 байта.

Я уже упоминал выше, что размер переменной в памяти зависит от ее типа, да и вообще говоря, оператор sizeof может оперировать и самими типами данных:

(gdb) print sizeof(int) $7 = 4 (gdb) print sizeof(double) $8 = 8
Это означает, что по меньшей мере на моей машине, переменные типа int занимают четыре байта, а типа double – восемь байт.

В GDB есть мощный инструмент для непосредственного исследования памяти – команда x . Эта команда проверяет память, начиная с определенного адреса. Также она имеет ряд команд форматирования, которые обеспечиваю точный контроль над количеством байт, которые Вы захотите проверить, и над тем, в каком виде Вы захотите вывести их на экран. В случае каких либо трудностей, наберите help x в командной строке GDB.

Как Вы уже знаете, оператор & вычисляет адрес переменной, а это значит, что можно передать команде x значение &i и тем самым получить возможность взглянуть на отдельные байты, скрывающиеся за переменной i :

(gdb) x/4xb &i 0x7fff5fbff584: 0x39 0x05 0x00 0x00
Флаги форматирования указывают на то, что я хочу получить четыре (4 ) значения, выведенные в шестнадцатеричном (hex ) виде по одному байту (b yte). Я указал проверку только четырех байт, потому что именно столько занимает в памяти переменная i . Вывод показывает побайтовое представление переменной в памяти.

Но с побайтовым выводом связана одна тонкость, которую нужно постоянно держать в голове – на машинах Intel байты хранятся в порядке “от младшего к старшему ” (справа налево), в отличии от более привычной для человека записи, где младший байт должен был бы находиться в конце (слева направо).

Один из способов прояснить этот вопрос – это присвоить переменной i более интересное значение и опять проверить этот участок памяти:

(gdb) set var i = 0x12345678 (gdb) x/4xb &i 0x7fff5fbff584: 0x78 0x56 0x34 0x12

Исследуем память с командой ptype

Команда ptype возможно одна из моих самых любимых. Она показывает тип С-го выражения:

(gdb) ptype i type = int (gdb) ptype &i type = int * (gdb) ptype main type = int (void)
Типы в С могут становиться сложными , но ptype позволяет исследовать их в интерактивном режиме.

Указатели и массивы

Массивы являются на удивление тонким понятием в С. Суть этого пункта в том, чтобы написать простенькую программу, а затем прогонять ее через GDB, пока массивы не обретут какой-то смысл.

Итак, нам нужен код программы с массивом array.c :

Int main() { int a = {1, 2, 3}; return 0; }
Скомпилируйте ее с флагом -g , запустите в GDB, и с помощь next перейдите в строку инициализации:

$ gcc -g arrays.c -o arrays $ gdb arrays (gdb) break main (gdb) run (gdb) next
На этом этапе Вы сможете вывести содержимое переменной и выяснить ее тип:

(gdb) print a $1 = {1, 2, 3} (gdb) ptype a type = int
Теперь, когда наша программа правильно настроена в GDB, первое, что стоит сделать – это использовать команду x для того, чтобы увидеть, как выглядит переменная a “под капотом”:

(gdb) x/12xb &a 0x7fff5fbff56c: 0x01 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x7fff5fbff574: 0x03 0x00 0x00 0x00
Это означает, что участок памяти для массива a начинается по адресу 0x7fff5fbff56c . Первые четыре байта содержат a , следующие четыре – a , и последние четыре хранят a . Действительно, Вы можете проверить и убедится, что sizeof знает, что a занимает в памяти ровно двенадцать байт:

(gdb) print sizeof(a) $2 = 12
До этого момента массивы выглядят такими, какими и должны быть. У них есть соответствующий массивам типы и они хранят все значения в смежных участках памяти. Однако, в определенных ситуациях, массивы ведут себя очень схоже с указателями! К примеру, мы можем применять арифметические операции к a :

(gdb) print a + 1 $3 = (int *) 0x7fff5fbff570
Нормальными словами, это означает, что a + 1 – это указатель на int , который имеет адрес 0x7fff5fbff570 . К этому моменту Вы должны уже рефлекторно передавать указатели в команду x , итак посмотрим, что же получилось:

(gdb) x/4xb a + 1 0x7fff5fbff570: 0x02 0x00 0x00 0x00

Обратите внимание, что адрес 0x7fff5fbff570 ровно на четыре единицы больше, чем 0x7fff5fbff56c , то есть адрес первого байта массива a . Учитывая, что тип int занимает в памяти четыре байта, можно сделать вывод, что a + 1 указывает на a .

На самом деле, индексация массивов в С является синтаксическим сахаром для арифметики указателей: a[i] эквивалентно *(a + i) . Вы можете проверить это в GDB:

(gdb) print a $4 = 1 (gdb) print *(a + 0) $5 = 1 (gdb) print a $6 = 2 (gdb) print *(a + 1) $7 = 2 (gdb) print a $8 = 3 (gdb) print *(a + 2) $9 = 3
Итак, мы увидели, что в некоторых ситуациях a ведет себя как массив, а в некоторых – как указатель на свой первый элемент. Что же происходит?

Ответ состоит в следующем, когда имя массива используется в выражении в С, то оно “распадается (decay)” на указатель на первый элемент. Есть только два исключения из этого правила: когда имя массива передается в sizeof и когда имя массива используется с оператором взятия адреса & .

Тот факт, что имя a не распадается на указатель на первый элемент при использовании оператора & , порождает интересный вопрос: в чем же разница между указателем, на который распадается a и &a ?

Численно они оба представляют один и тот же адрес:

(gdb) x/4xb a 0x7fff5fbff56c: 0x01 0x00 0x00 0x00 (gdb) x/4xb &a 0x7fff5fbff56c: 0x01 0x00 0x00 0x00
Тем не менее, типы их различны. Как мы уже видели, имя массива распадается на указатель на его первый элемент и значит должно иметь тип int * . Что же касается типа &a , то мы можем спросить об этом GDB:

(gdb) ptype &a type = int (*)
Говоря проще, &a – это указатель на массив из трех целых чисел. Это имеет смысл: a не распадается при передаче оператору & и a имеет тип int .

Вы можете проследить различие между указателем, на который распадается a и операцией &a на примере того, как они ведут себя по отношению к арифметике указателей:

(gdb) print a + 1 $10 = (int *) 0x7fff5fbff570 (gdb) print &a + 1 $11 = (int (*)) 0x7fff5fbff578
Обратите внимание, что добавление 1 к a увеличивает адрес на четыре единицы, в то время, как прибавление 1 к &a добавляет к адресу двенадцать.

Указатель, на который на самом деле распадается a имеет вид &a :

(gdb) print &a $11 = (int *) 0x7fff5fbff56c

Заключение

Надеюсь, я убедил Вас, что GDB – это изящная исследовательская среда для изучения С. Она позволяет выводить значение выражений с помощью команды print , побайтово исследовать память командой x и работать с типами с помощью команды ptype .

1. Используйте GDB для работы над The Ksplice Pointer Challenge .
2. Разберитесь, как структуры хранятся в памяти. Как они соотносятся с массивами?
3. Используйте дизассемблерные команды GDB, чтобы лучше разобраться с программированием на ассемблере. Особенно весело исследовать, как работает стек вызова функции.
4. Зацените “TUI” режим GDB, который обеспечивает графическую ncurses надстройку над привычным GDB. На OS X, Вам вероятно придется собрать GDB из исходников.

От переводчика: Традиционно для указания ошибок воспользуйтесь ЛС. Буду рад конструктивной критике.

Сегодня ты сделаешь еще один шаг в деле
изучения Linux систем. Я расскажу об основных
приемах при работе с gdb. Овладев ими ты сможешь понять, как работает любая программа, писать свои эксплоиты.

Вы, наверное, все слышали про такую вещь как отладчик, gdb – это и есть отладчик. GDB – GNU
Debugger. Это некое подобие SoftICE для Windows (для тех кто не знает – самый популярный и, на мой взгляд, вообще лучший отладчик), только под
Linux системы. Дело в том, что в сети не так уж много документов, которые демонстрируют работу этой вещи и в свое время я его осваивал сам. Итак,
в документе будут описаны базовые команды gdb. Все это будет показано на примере. А в качестве примера я решил взять ненужную прогу yes. Для тех, кто не знает – это программа просто выводит символ ‘y’ до бесконечности, для начала я решил научить ее выводить не этот символ, а строку ‘XAKEP’, хоть веселее будет.

Ну а теперь все по порядку. Сам отладчик запускается так:

Но можно вводить различные параметры, у нас это будет путь к исследуемой программе:

# gdb /usr/bin/yes

Можно исследовать core файлы, для этого нужно ввести следует ввести следующее:

# gdb /usr/bin/yes core

Еще может понадобится команда для просмотра содержимого регистров:

(gdb) info registers

либо так (сокращенный вариант)

Теперь рассмотрим как делать перехваты. Существуют
точки останова, точки перехвата и точки наблюдения. Более конкретно я бы хотел остановиться на точках останова. Их можно устанавливать на:

(gdb) break function - Остановить перед входом в функцию
(gdb) break *adress - Остановить перед выполнением инструкции по адресу.

После установок можно просмотреть все точки для этого воспользуйтесь командой:

(gdb) info break

А потом можно удалить эти точки:

(gdb) clear breakpoint - где break это название точки останова
(например, функция или адрес)

Очень необходимой вещью является возможность автоматического отображения различных значений при выполнении программы. Для этого существует команда display:

(gdb) display/format value , где format – это формат отображения, а value – само выражение которое нужно отобразить.

Для работы с отображением отведены следующие команды:

(gdb) info display - выдает инфу об отображениях
(gdb) delete num - где num – удалить элементы с индексом
num

Это был небольшой справочник по командам, чтобы понять основную идею.
Далее на примере хотелось бы продемонстрировать это и еще немного. И помните – здесь я дал лишь очень маленькую часть всех возможностей gdb, на самом деле у него их в сотни раз больше, поэтому читайте и учите.
Как я и обещал, берем ненужную прогу yes. Путь на вашей машине может не совпадать с моим, все зависит от операционки которой вы пользуетесь, если что воспользуйтесь поиском (команда
find).

# gdb /usr/bin/yes

После запуска он говорит приветственное сообщение.

GNU gdb 19991004

There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...

Так как yes выводит бесконечное число символов, то лучше бы их нам не видеть в отладчике, а вывод
программы можно направить на другую консоль. Откройте новый терминал, наберите who is i и вы получите имя консоли. Должно вылезти
что-то вроде этого:

Вот теперь просто привязываем к ней.

(gdb) tty /dev/pts/1

А теперь ставим точку останова на функцию puts(), а чтобы было понятней вот вам man-справка об функции(команда man
puts)

#include
int puts(const char *s);
puts() writes the string s and a trailing newline to std
out.

Как видно, функция посылаем строку s на поток вывода. Вот она то нам и нужна. На ней то мы пока и остановимся.

(gdb) break puts
Breakpoint 1 at 0x8048698

И запускаем саму программу, чтобы дождаться пока gdb не остановит ее выполнение на вызове функции.

(gdb) r
Starting program: /usr/bin/yes
Breakpoint 1 at 0x4006d585: file ioputs.c, line 32.

Breakpoint 1, 0x4006d585 in _IO_puts (str=0x8048e59 "y") at ioputs.c:32
32 ioputs.c: No such file or directory.
1: x/i $eip 0x4006d585 <_IO_puts+21>: mov 0x8(%ebp),%esi

О, вот и произошло чудо, сработал breakpoint. Что мы видим – а видим мы ни что иное, как параметр функции, точнее адрес, по которому он лежит. Что теперь нужно
сделать? Правильно, подправить данные по этому адресу. При этом мы затрем еще пару символов своими.

(gdb) set {char}0x8048e59="X"
(gdb) set {char}0x8048e5a="A"
(gdb) set {char}0x8048e5b="K"
(gdb) set {char}0x8048e5c="E"
(gdb) set {char}0x8048e5d="P"

Ну а теперь посмотрим на наше творение. Что там лежит в памяти:

(gdb) x/3sw 0x8048e59
0x8048e59 <_IO_stdin_used+437>: "XAKEP\004\b"
0x8048e61 <_IO_stdin_used+445>: ""
0x8048e62 <_IO_stdin_used+446>: ""

Теперь удалим наш брякпоинт:

(gdb) info break
Num Type Disp Enb Address What
1 breakpoint keep y 0x4006d585 in _IO_puts at ioputs.c:32
breakpoint already hit 1 time
(gdb) clear puts
Deleted breakpoint 1

И продолжим выполнение чтобы насладится результатом:

Вот и все. Выходим.

(gdb) q
The program is running. Exit anyway? (y or n) y

На этом практика заканчивается, остальное изучайте сами и помните что главное в этой жизни – это УЧЕНЬЕ.
Вот еще некоторые примеры работы:

Присоединение к работающему процессу:

// launch gdb
hack@exploit:~ > gdb
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or 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.
This GDB was configured as "i386-suse-linux".
(gdb) attach "pid"
(gdb) attach 1127 // example

Поиск в памяти:

(gdb) x/d or x "address" show decimal
(gdb) x/100s "address" show next 100 decimals
(gdb) x 0x0804846c show decimal at 0x0804846c
(gdb) x/s "address" show strings at address
(gdb) x/105 0x0804846c show 105 strings at 0x0804846c
(gdb) x/x "address" show hexadecimal address
(gdb) x/10x 0x0804846c show 10 addresses at 0x0804846c
(gdb) x/b 0x0804846c show byte at 0x0804846c
(gdb) x/10b 0x0804846c-10 show byte at 0x0804846c-10
(gdb) x/10b 0x0804846c+20 show byte at 0x0804846c+20
(gdb) x/20i 0x0804846c show 20 assembler instructions at address

Список всех секций в исполняемом файле:

(gdb) maintenance info sections // or
(gdb) mai i s

Executable file:
`/home/hack/homepage/challenge/buf/basic", file type
elf32-i386.
0x080480f4->0x08048107 at 0x000000f4: .interp ALLOC

0x08048108->0x08048128 at 0x00000108: .note.ABI-tag
ALLOC LOAD READONLY DATA HAS_CONTENTS
0x08048128->0x08048158 at 0x00000128: .hash ALLOC
LOAD READONLY DATA HAS_CONTENTS
0x08048158->0x080481c8 at 0x00000158: .dynsym ALLOC
LOAD READONLY DATA HAS_CONTENTS
0x080481c8->0x08048242 at 0x000001c8: .dynstr ALLOC
LOAD READONLY DATA HAS_CONTENTS
0x08048242->0x08048250 at 0x00000242: .gnu.version
ALLOC LOAD READONLY DATA
HAS_CONTENTS

Бряк на адрес:

(gdb) disassemble main
Dump of assembler code for function main:
0x8048400

: push %ebp
0x8048401 : mov %esp,%ebp
0x8048403 : sub $0x408,%esp
0x8048409 : add $0xfffffff8,%esp
0x804840c : mov 0xc(%ebp),%eax
0x804840f : add $0x4,%eax
0x8048412 : mov (%eax),%edx
0x8048414 : push %edx
0x8048415 : lea 0xfffffc00(%ebp),%eax
...

(gdb) break *0x8048414 // example
Breakpoint 1 at 0x8048414
(gdb) break main // example
Breakpoint 2 at 0x8048409
(gdb)

Ошибки, к сожалению, встречаются в любой программе, каким бы крутым профессионалом её разработчик ни был. Поэтому, нравится это вам или нет, пользоваться отладчиком вам всё равно придётся. Жизнь заставит. И чем больше времени вы сейчас потратите на изучение работы с ним, тем больше времени это вам сэкономит в дальнейшем.

Мы рассмотрим отладчик GDB, входящий в комплект программ GNU.

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

Такая компиляция достигается путём добавления флага -g к команде на компиляцию. Например, если бы мы собирали программу kalkul без применения Makefile, мы бы дали такую команду:

g++ main.cpp problem.cpp -o kalkul -g

Если же мы пользуемся командой make, то надо поставить опцию CFLAGS=-g. Тогда все команды на компиляцию, содержащиеся в Make-файле, автоматически получат флаг -g.

Давайте возьмём программу, которую мы создали из файлов main.cpp, problem.cpp и problem.h (мы тогда называли этот каталог проекта kalkulcpp). У нас Makefile уже сформирован. Воспользуемся им.

Очистим пакет от результатов предыдущей сборки.

Соберём программу снова, но уже с включением отладочной информации.

Запустим отладчик GDB, загрузив в него нашу программу для отладки. (Если помните, исполняемая программа у нас находилась в каталоге src.)

gdb ./src/kalkul

Чтобы запустить программу внутри отладчика,даётся команда run.

Чтобы посмотреть исходный код, даётся команда list.

Если дать эту команду без параметров, то она первые девять строк исходного кода главного файла (то есть такого, в котором имеется функция main). Чтобы просматривать файл дальше, надо снова набирать list. Чтобы посмотреть конкретные строки, надо указать два параметра: с какой строки начинать просмотр, и с какой строки заканчивать.

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

list problem.cpp:20,29

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

list problem.cpp:20,27

Посмотреть, где вы поставили точки останова, можно с помощью команды info breakpoints.

info breakpoints

(При желании можно вместо номера строки указать название функции,тогда программа остановится перед входом в функцию.)

Запустим программу.

Введём первое число 5 и знак математического действия « + ». Программа дойдёт до точки останова и остановится, выведя нам строку, у которой эта точка расположена.

Нам, конечно, интересно знать,в каком именно месте мы остановились, и что программа уже успела выполнить. Даём команду backtrace.

Отладчик выдаёт нам следующую информацию:

#0 CProblem::Calculate (this=0x804b008) at problem.cpp:21

#1 0x08048e00 in CProblem::Solve (this=0x804b008) at problem.cpp:93

#2 0x08048efc in main () at main.cpp:15

Это означается, что мы находимся внутри выполняющейся функции Calculate, являющейся функцией-членом класса CProblem. Она была вызвана из функции Solve того же класса, а та, в свою очередь, из функции main. Таким образом, команда backtrace показывает весь стек вызываемых функций от начала программы до текущего места.

Посмотрим, чему же равно на этом этапе значение переменной Numeral.

И нам сразу выводится число 5, которое мы и вводили в программу. (Значение, введённое нами с клавиатуры, присвоилось именно этой переменной.)

Если мы вместо print будем пользоваться командой display, то величина этой переменной будет показываться каждый раз, когда программа останавливается, без специального указания.

Добавим ещё одну точку останова на строке 25 файла problem.cpp.

break problem.cpp:25

Продолжим выполнение программы.

Команда Continue продолжает выполнение программы с текущего адреса. Если бы мы набрали run, программа начала бы выполняться с начала. Поскольку на строке 24 имеется команда cin >> SecondNumeral, то нам придётся ввести второе слагаемое. Введём, например,число 2. После этого программа опять остановится на строке 25 (наша вторая точка останова).

Посмотрим, чему равны значения наших переменных Numeral, SecondNumeral и Operation. Если вы помните, именно такие переменные мы объявляли в классе CProblem.

print SecondNumeral

У нас получится 5, « + », 2. Так и должно быть. Но давайте теперь «передумаем» и лучше присвоим переменной SecondNumeral значение 4. Отладчик GDB позволяет прямо во время выполнения программы изменить значение любой переменной.

set SecondNumeral=4

Если не верим, что её значение изменилось,можно проверить.

print SecondNumeral

Теперь мы ожидаетм, что результат будет 9. Давайте выполним программу до конца.

Результат действительно равен 9.

Давайте теперь уберём наши точки останова. Мы, кажется, создали две таких точки. Но это можно проверить.

info breakpoints

Удалим их.

Унас не должно остаться ни одной точки останова. Проверяем.

info breakpoints

Действительно не осталось ни одной.

Теперь давайте пошагово пройдём всю программу (благо, она у нас небольшая).

Поставим точку останова на десятой строке главного файла.

break main.cpp:10

Запустим программу

Дойдя до десятой строчки, она остановится. Теперь проходим её, останавливаясь на каждой строчке, с помощью команды step.

Чтобы не набирать каждый раз s-t-e-p, можно просто вводить букву s. Как только программа доходит до команды Problem->SetValues(), она сразу переходит в файл problem.cpp, где находится определение функции-члена CProblem::SetValues() и проходит код этой функции. То же самое, когда она дойдёт до вызова Problem->Solve().

Чтобы при вызове функции, программа не входила в неё, а продолжала дальше выполняться только на текущем уровне стека, вместо step даётся команда next или просто n.

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

Дадим короткий список наиболее часто встречающихся команд отладчика GDB. За более подробной информацией вы, конечно, всегда можете обратиться к встроенному описанию программы (info gdb) или руководством по пользованию (man gdb).

backtrace - выводит весь путь к текущей точке останова, то есть названия всех функций, начиная от main(); иными словами, выводит весь стек функций;

break - устанавливает точку останова; параметром может быть номер строки или название функции;

clear - удаляет все точки останова на текущем уровне стека (то есть в текущей функции);

continue - продолжает выполнение программы от текущей точки до конца;

delete - удаляет точку останова или контрольное выражение;

display - добавляет выражение в список выражений, значения которых отображаются каждый раз при остановке программы;

finish - выполняет программу до выхода из текущей функции; отображает возвращаемое значение,если такое имеется;

info breakpoints - выводит список всех имеющихся точек останова;

info watchpoints - выводит список всех имеющихся контрольных выражений;

list - выводит исходный код; в качестве параметра передаются название файла исходного кода, затем, через двоеточие, номер начальной и конечной строки;

next - пошаговое выполнение программы, но, в отличие от команды step, не выполняет пошагово вызываемые функции;

print - выводит значение какого-либо выражения (выражение передаётся в качестве параметра);

run - запускает программу на выполнение;

set - устанавливает новое значение переменной

step - пошаговое выполнение программы;

watch - устанавливает контрольное выражение, программа остановится, как только значение контрольного выражения изменится;

Дмитрий Пантелеичев (dimanix2006 at rambler dot ru) - Знакомство с отладчиком gdb

Поговорим об отладчиках для Microsoft Windows. Их существует довольно много, вспомнить хотя бы всеми любимый OllyDbg, некогда популярный, но в настоящее время практически умерший SoftIce, а также Sycer, Immunity Debugger, x64dbg и бесчисленное количество отладчиков, встроенных в IDE. По моим наблюдениям, WinDbg нравится далеко не всем. Думаю, в основном это связано с командным интерфейсом отладчика. Любителям Linux и FreeBSD, бесспорно, он пришелся бы по душе. Но закоренелым пользователям Windows он кажется странным и неудобным. А тем временем, по функционалу WinDbg ничем не уступает другим отладчикам. Как минимум, он точно нечем не хуже классического GDB или там LLDB . В чем мы сегодня с вами и убедимся.

В мире Windows, все, как обычно, немного через жопу. Официальный инсталятор WinDbg можно скачать на сайте MS. Инсталятор этот помимо WinDbg также поставит вам свежую версию.NET Framework и перезагрузит систему без спроса. После установки не факт, что отладчик вообще заработает, особенно под старыми версиями Windows. Поэтому лучше скачать неофициальную сборку WinDbg или . Настоятельно советую воспользоваться именно одной из этих версий — это самый простой и быстрый способ установить WinDbg.

Есть две версии WinDbg, x86 и x64. Чтобы не возникало никаких проблем, отлаживайте x86 приложения с помощью x86 дебагера, а x64 приложения — с помощью x64 дебагера. После первого запуска выглядеть WinDbg будет довольно убого. Но не беспокойтесь по этому поводу. Поработав буквально несколько минут с WinDbg, вы подстроите его под себя и выглядеть он будет вполне няшненько. Например, как-то так (кликабельно, 51 Кб, 1156 x 785):

На этом скриншоте изображена отладка программы из заметки Получаем список запущенных процессов на Windows API . Как видите, WinDbg подцепил исходники программы. Справа отображаются значения локальных переменных. Внизу находится окно для ввода команд, где при помощи команды kn был выведен стэк вызовов. В верхней части отладчика находятся кнопки, при помощи которых можно выполнять простые действия вроде «шаг вперед», а также открыть дополнительные окна. При помощи этих окон можно посмотреть содержимое оперативной памяти, значения регистров, дизассемблерный листинг программы и много других интересных вещей.

Вообще, очень многое в WinDbg можно делать через GUI. Например, в окне с исходным кодом можно поставить курсор на нужном месте и нажатием на икноку с ладонью создать там точку останова. Или выполнить run to cursor. Также выполнение команды можно в любой момент остановить при помощи кнопки Break в панели вверху. На этом всем подробно останавливаться не будем. Но учтите, что такие возможности есть и они заслуживают изучения!

Прежде, чем приступить к отладке при помощи WinDbg, нужно сделать несколько несложных телодвижений. Откройте File → Symbol File Path и введите:

SRV*C:\symbols*http://msdl.microsoft.com/download/symbols

Затем нажмите Browse и укажите путь до файлов c отладочной информацией (.pdb) вашего проекта. Аналогичным образом в File → Source File Path укажите путь до каталога с исходниками. Если сомневаетесь, укажите путь, по которому находится файл проекта Visual Studio, не ошибетесь. Затем скажите File → Save Workspace, чтобы все эти пути не приходилось указывать заново при каждом запуске WinDbg.

Теперь, когда все настроено, есть несколько способов начать отладку. Можно запустить новый процесс под отладчиком, можно подключиться к уже существующему, можно открыть крэшдамп. Все это делается через меню File. Особого внимания заслуживает возможность удаленной отладки. Например, если при помощи WinDbg вы отлаживаете драйверы, то особого выбора, кроме как использовать удаленную отладку, у вас как бы и нет. Что не удивительно, ведь малейшая ошибка в коде драйвера может привести к BSOD.

Если вы уже отлаживаете процесс, но хотели бы начать делать это удаленно, говорим:

Server tcp:port=3003

Нужно проверить, что порт открыт, что особенно актуально на Windows Server. На клиенте делаем File → Connect to a Remote Session, вводим:

tcp:Port=3003,Server=10.110.0.10

Кроме того, можно запустить сервер, позволяющий отлаживать любой процесс в системе:

dbgsrv.exe -t tcp:port=3003

На клиенте подключаемся через File → Connect to Remote Stub. После этого через интерфейс можно как обычно выбрать процесс из списка или запустить новый. Только работать процессы будут на удаленной машине.

Теперь, наконец-то, рассмотрим основные команды WinDbg.

Важно! Иногда команды могут выполняется очень долго, например, если вы решили загрузить сразу все отладочные символы. Если устанете ждать, просто нажмите Ctr+C в поле ввода команды, и WinDbg тут же перестанет делать то, что он сейчас делает.

Help
.hh команда

Очистить вывод в окне Command:

Добавить путь, по которому WinDbg будет искать отладочные символы (та же команда без знака плюс затрет все ранее прописанные пути):

Sympath+ c:\pdbs

Перезагрузить символы:

Показать список модулей:

Ищем символы:

x *!Ololo::My::Namespace::*

Загрузить символы для модуля:

ld имя_модуля

Если WinDbg почему-то не находит.pdb файлы и в стектрейсах вместо имен.c/.cpp файлов с номерами строк вы видите что-то вроде module+0x19bc, попробуйте выполнить следующую последовательность команд — так вы получите больше информации о возможных причинах проблемы:

Sym noisy
.reload MyModule.dll

Указать путь к каталогу исходников:

Поставить точку останова:

bp kernel32!CreateProcessA
bp `mysorucefile.cpp:123`
bp `MyModule!mysorucefile.cpp:123`
bp @@(Full::Class:Name::method)

Поставить точку остановка, которая сработает только один раз:

Поставить точку останова, которая сработает на 5-ый раз, после 4-х проходов:

Можно автоматически выполнять команды каждый раз, когда срабатывает точка останова:

bp kernel32!LoadLibraryA ".echo \"Variables:\n\"; dv"

У аппаратных точек останова синтаксис такой:

Где mode это e, r или w — выполнение, чтение, запись. При mode = e параметр size может быть только 1. Например:

ba e 1 kernel32!LoadLibraryA

Список точек останова: