GDB

Глава 4 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: GDB
Автор: Stan Shebs
Дата публикации: 26 Апреля 2012 г.
Перевод: А.Панин
Дата перевода: 16 Сентября 2013 г.

Creative Commons. Перевод был сделан в соответствие с лицензией Creative Commons. С русским вариантом лицензии можно ознакомиться здесь.

GDB или отладчик GNU был одной из первых программ, разработанных для нужд Фонда свободного программного обеспечения и ставших важнейшим элементом экосистемы распространяемого под свободными лицензиями программного обеспечения с открытым исходным кодом с момента разработки. Изначально архитектура приложения подразумевала его использование в роли обычного отладчика уровня исходного кода для Unix, но с тех пор она подверглась расширению для добавления широкого спектра вариантов использования, включая использование отладчика во многих встраиваемых системах, причем кодовая база приложения увеличилась с нескольких тысяч до полумиллиона строк на языке C.

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

4.1. Цель разработки

% gdb myprog
[...]
(gdb) break buggy_function
Breakpoint 1 at 0x12345678: file myprog.c, line 232.
(gdb) run 45 92
Starting program: myprog
Breakpoint 1, buggy_function (arg1=45, arg2=92) at myprog.c:232
232     result = positive_variable * arg1 + arg2;
(gdb) print positive_variable
$$1 = -34
(gdb)

GDB сообщает о том, что с отлаживаемым приложением что-то не так, разработчик говорит "ага" или "гммм", после чего ему предстоит дать ответы на вопросы о том, в чем заключается ошибка и как ее исправить.

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

У GDB также должна быть возможность отладки программ, скомпилированных с помощью сторонних компиляторов (не только компилятора GNU C), программ, скомпилированных давным-давно с помощью устаревших версий компиляторов, а также программ, информация о символах которых отсутствует, устарела или просто является некорректной; следовательно, еще одно архитектурное решение должно заключаться в том, что отладчик GDB должен продолжать работать и успешно выполнять поставленные перед ним задачи даже в том случае, если данные, относящиеся к внутреннему устройству приложения, отсутствуют, повреждены или просто некорректны.

В последующих разделах будут рассматриваться вопросы, подразумевающие наличие у читателя опыта использования интерфейса командной строки GDB. Если вы практически не знакомы с GDB, займитесь изучением руководства. [SPS+00].

4.2. Начало развития GDB

GDB является довольно старой программой. Он начал свое существование примерно в 1985 году как разработка от Richard Stollman, поставляемая вместе с GCC, GNU Emacs и другими ранними версиями компонентов проекта GNU. (В это время не существовало публичных репозиториев систем контроля версий, поэтому большая часть подробностей истории разработки на данный момент потеряна.)

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

Продолжение статьи: Блочная диаграмма