Реклама на портале

Изучаем С используя GDB. Основы использования отладчика WinDbg Аргументы вашей программы

Linux: Полное руководство Колисниченко Денис Николаевич

22.2. Отладчик gdb

22.2. Отладчик gdb

Формат вызова отладчика gdb следующий:

gdb [-help] [-nx] [-q] [-batch] [-cd=dir] [-f] [-b bps] [-tty=dev] [-s symfile] [-e prog] [-sе prog] [-c core] [-x cmds] [-d dir] ]

Ключи отладчика описаны в таблице 22.1.

Ключи командной строки gdb Таблица 22.1

Ключ Назначение
-help или -h Вывод краткого описания всех параметров
-nx или -n Не обрабатывать команды файла инициализации.gdbinit
-q Не выводить приветствие и информацию об авторских правах
-batch Командный режим. Отладчик возвращает 0, если были выполнены все команды, указанные в файле, заданном параметром -x (и файле.gdbinit, если его использование разрешено). Если же хотя бы одна из команд не выполнена, возвращается ненулевое значение
-cd=каталог Установить рабочий каталог (по умолчанию используется текущий каталог)
-f или -fullname Данная опция нужна, если вы планируете использовать интерфейс текстового процессора Emacs для отладки ваших программ с помощью gdb . Для более подробного описаний обратитесь к справочной системе
-b bps (bits per second) Установить скорость обмена информацией по последовательному интерфейсу, если вы отлаживаете вашу программу удаленно
-tty=терминал Установить терминал в качестве стандартного ввода и вывода для отлаживаемой программы.
-s файл или -symbols=файл Читает таблицу символов из указанного файла
-write Разрешить запись в исполняемые и core-файлы
-e программа Использовать указанную программу в качестве фильтра дампа
-se=файл Читать таблицу символов из указанного файла и использовать указанный файл в качестве исполнимого
-core=файл или -с файл Указать файл дампа
-command=файл или -x файл Выполнить указанные в файле команды (используется в командном режиме)
-d каталог Добавить каталог к списку поиска исходных текстов
Последний параметр задает объект, который нужно отлаживать. Вы можете задать программу (prog), или дамп-файл (core), который будет создан в случае ошибки программы (Segmentation fault), или же подсоединиться к уже запущенному процессу (procID)
-p PID Подключиться к уже запущенному процессу (данная опция стала доступной в версии gdb 5.2)

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

$ gcc -g -o prog prog.c

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

Затем нужно вызвать gdb так:

Если после запуска вашей программы произошла ошибка и был создан дамп-файл (core), можно передать отладчику и этот файл:

Можно также подключиться к уже запущенному процессу, для этого нужно передать его PID:

Только убедитесь сначала в том, что у вас нет файла 1111, поскольку gdb сначала ищет исполняемый файл, затем core-файл, а уже затем PID.

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

Команды gdb Таблица 22.2

Команда Назначение
break [файл:]функция Установить точку останова
run [аргументы] Запустить программу и передать ей указанные аргументы
bt Обратная трассировка: отобразить стек программы
print выражение Вывести значение выражении, операндами могут быть переменные, объявленные в вашей программа
С Продолжить выполнение программы (после останова)
Next Выполнить следующую строку. Это так называемый шаг «над» (step over). Если следующая строка - вызов функции, то мы выполним ее за один шаг - «перешагнем» ее
Step Выполнить следующую строку, Это так называемый шаг «в» (step into). Если следующая строка - вызов функции, то мы будем последовательно выполнять все операторы тела функции
help [имя] Вывести справку о команде отладчика или вывести общую информацию о нем
Quit Выход

В данной таблице приведены далеко не все команды. Если вас интересует более полная информация, обратитесь к руководству по gdb .

Из книги Язык программирования С# 2005 и платформа.NET 2.0. автора Троелсен Эндрю

Отладчик командной строки (cordbg.exe) Прежде чем перейти к рассмотрению возможностей компоновки C#-приложе-ний с помощью TextPad, следует отметить, что.NET Framework 2.0 SDK предлагает отладчик командной строки cordbg.ехe. Этот инструмент имеет множество опций, которые позволяют выполнить

Из книги Разработка приложений в среде Linux. Второе издание автора Джонсон Майкл К.

4.3. Отладчик GNU gdb - это отладчик, рекомендуемый Free Software Foundation, gdb представляет собой хороший отладчик командной строки, на котором строятся некоторые инструменты, включая режим gdb в Emacs, графический отладчик Data Display Debugger (http://www.gnu.org/software/ddd/) и встроенные отладчики в некоторых

Из книги Linux: Полное руководство автора Колисниченко Денис Николаевич

22.2. Отладчик gdb Формат вызова отладчика gdb следующий:gdb [-help] [-nx] [-q] [-batch] [-cd=dir] [-f] [-b bps] [-tty=dev] [-s symfile] [-e prog] [-sе prog] [-c core] [-x cmds] [-d dir] ]Ключи отладчика описаны в таблице 22.1.Ключи командной строки gdb Таблица 22.1 Ключ Назначение -help или -h Вывод краткого описания всех

Из книги Программирование для Linux. Профессиональный подход автора Митчелл Марк

1.4. GNU-отладчик gdb Отладчик - это программа, с помощью которой можно узнать, почему написанная вами программа ведет себя не так, как было задумано. Работать с отладчиком приходится очень часто. Большинство Linux-программистов имеет дело с GNU-отладчиком (GNU Debugger, GDB), который

Из книги Разработка ядра Linux автора Лав Роберт

Отладчик kgdb Отладчик kgdb - это заплата ядра, которая позволяет с помощью отладчика gdb отлаживать ядро по линии последовательной передачи. Для этого требуется два компьютера. На первом выполняется ядро с заплатой kgdb. Второй компьютер используется для отладки ядра по линии

Сегодня ты сделаешь еще один шаг в деле
изучения 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)

Поговорим об отладчиках для 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"

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

ba

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

ba e 1 kernel32!LoadLibraryA

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

Деактивировать точку останова:

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

Полное удаление точек останова:

bc номер
bc *

Показать команды, которые нужно ввести для восстановления текущих точек останова:

Писать лог в файл:

Logopen c:\1.txt

Перестать писать лог в файл:

Выполнить команды из файла:

Для сохранения точек останова в файл можно выполнить (обязательно в одну строку!) следующие команды:

Logopen c:\1.txt; .bpcmds; .logclose

Показать дизассемблерный листинг:

Показать значение регистров:

Показать стек вызовов:

То же самое с номерами фреймов:

Перемещение к фрейму:

Frame номер

Показать локальные переменные:

Показать структуру:

dt имя_переменной

Показать структуру рекурсивно:

dt -r имя_переменной

Дамп памяти по адресу:

Дамп памяти в виде word/dword/qword:

dw адрес
dd адрес
dq адрес

Дамп в виде битов:

Дамп ascii строки:

Дамп unicode строки:

Редактирование памяти.

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, как

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

Чтобы запросить генерацию отладочной информации, укажите ключ `-g" при запуске компилятора.

Многие компиляторы Си не могут обрабатывать ключи `-g" и `-O" вместе. Используя такие компиляторы, вы не можете создавать оптимизированные выполняемые файлы, содержащие отладочную информацию.

GCC, GNU компилятор Си, поддерживает `-g" с или без `-O" , делая возможным отладку оптимизированного кода. Мы рекомендуем, чтобы вы всегда использовали `-g" при компиляции программ. Вы можете думать, что ваша программа правильная, но нет никакого смысла испытывать удачу.

Если вы запускаете вашу программу в среде выполнения, поддерживающей процессы, run создает подчиненный процесс, и этот процесс выполняет вашу программу. (В средах, не поддерживающих процессы, run выполняет переход на начало вашей программы.)

Выполнение программы зависит от определенной информации, которую она получает от породившего ее процесса. GDB предоставляет способы задать эту информацию, что вы должны сделать до запуска программы. (Вы можете изменить ее после старта, но такие изменения воздействуют на вашу программу только при следующем запуске.) Эта информация может быть разделена на четыре категории: Параметры. Задайте параметры, которые нужно передать вашей программе, как параметры команды run . Если на вашей системе доступна оболочка, она используется для передачи параметров, так что при их описании вы можете использовать обычные соглашения (такие как раскрывание шаблонов или подстановка переменных). В системах Unix, вы можете контролировать, какая оболочка используется, с помощью переменной среды SHELL . См. раздел 4.3 Аргументы вашей программы . Среда. Обычно ваша программа наследует свою среду от GDB, но вы можете использовать команды GDB set environment и unset environment , чтобы изменить часть настроек среды, влияющих на нее. См. раздел 4.4 Рабочая среда вашей программы . Рабочий каталог. Ваша программа наследует свой рабочий каталог от GDB. Вы можете установить рабочий каталог GDB командой cd . См. раздел 4.5 Рабочий каталог вашей программы . Стандартный ввод и вывод. Обычно ваша программа использует те же устройства для стандартного ввода и вывода, что и GDB. Вы можете перенаправить ввод и вывод в строке команды run , или использовать команду tty , чтобы установить другое устройство для вашей программы. См. раздел 4.6 Ввод и вывод вашей программы . Предупреждение: Хотя перенаправление ввода и вывода работает, вы не можете использовать каналы для передачи выходных данных отлаживаемой программы другой программе; если вы попытаетесь это сделать, скорее всего GDB перейдет к отладке неправильной программы.

Когда вы подаете команду run , ваша программа начинает выполняться немедленно. См. раздел 5. Остановка и продолжение исполнения , для обсуждения того, как остановить вашу программу. Как только ваша программа остановилась, вы можете вызывать функции вашей программы, используя команды print или call . См. раздел 8. Исследование данных .

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

4.3 Аргументы вашей программы

Первое, что GDB делает после подготовки к отладке указанного процесса--останавливает его. Вы можете исследовать и изменять присоединенный процесс всеми командами GDB, которые обычно доступны, когда вы запускаете процессы с помощью run . Вы можете устанавливать точки останова; вы можете пошагово выполнять программу и продолжить ее обычное выполнение, вы можете изменять области данных. Если вы решите продолжить выполнение процесса после присоединения к нему GDB, вы можете использовать команду continue . detach Когда вы закончили отлаживать присоединенный процесс, для его освобождения из под управления GDB вы можете использовать команду detach . Отсоединение процесса продолжает его выполнение. После команды detach , этот процесс и GDB снова становятся совершенно независимыми, и вы готовы присоединить или запустить с помощью run другой процесс. detach не повторяется, если вы нажмете RET еще раз после выполнения команды.

Если вы выйдете из GDB или используете команду run , пока у вас есть присоединенный процесс, вы убьете этот процесс. По умолчанию, GDB запрашивает подтверждение, если вы пытаетесь сделать одну из этих вещей; вы можете контролировать, нужно вам это подтверждение или нет, используя команду set confirm (см. раздел 15.6 Необязательные предупреждения и сообщения).

4.8 Уничтожение дочернего процесса

kill Уничтожить дочерний процесс, в котором ваша программа выполняется под управлением GDB.

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

В некоторых операционных системах, программа не может быть выполнена вне GDB, пока у вас есть в ней точки останова, установленные отладчиком. В этой ситуации вы можете использовать команду kill , чтобы разрешить выполнение вашей программы вне отладчика.

Команда kill также полезна, если вы хотите перекомпилировать и перекомпоновать вашу программу, так как во многих системах невозможно модифицировать исполняемый файл во время выполнения процесса. В этом случае, когда вы в следующий раз введете run , GDB заметит, что файл изменился, и заново прочитает символьную таблицу (стараясь при этом сохранить ваши точки останова).