GDB

Глава 4 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: GDB
Автор: Stan Shebs
Перевод: А.Панин

4.9. Интерфейсы GDB

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

Интерфейс командной строки

Интерфейс командной строки использует стандартную библиотеку readline проекта GNU для посимвольной обработки пользовательского ввода. Библиотека readline заботится о таких вещах, как редактирование строк и завершение команд; пользователь может выполнять такие действия, как использование клавиш перемещения курсора для перехода к предыдущей строке и исправления символа.

После этого GDB принимает возвращаемую библиотекой readline команду и производит ее поиск в каскадной структуре таблиц команд, в которой при каждом успешном обнаружении управляющего слова производится выбор дополнительной таблицы. Например, команда set print elements 80 затрагивает три таблицы; первой является таблица всех доступных команд, второй - таблица параметров команды set, а третьей - таблица параметров вывода значений, в соответствии с которой elements является одним из ограничений, налагаемых на число объектов, выводимых при рассмотрении таких конструкций, как строка или массив. После того, как с помощью каскадной структуры была вызвана соответствующая функция для обработки команды, она получает контроль над процессом выполнения команды и обработка аргументов является исключительно ее задачей. Некоторые команды, такие, как run обрабатывают свои аргументы по аналогии со стандартом argc/argv, традиционным для языка C, в то время, как другие команды, такие, как print предполагают, что оставшаяся часть строки является единым выражением языка программирования и передают всю строку специфичной для языка программирования системе разбора синтаксических конструкций.

Машинный интерфейс

Одним способом реализации графического интерфейса для отладки является использование GDB в роли "обработчика команд" реализующей графический интерфейс программы, которая занимается преобразованием событий нажатия кнопок мыши в команды и форматированием выводимых результатов для их показа в окнах. Описанный подход использовался несколько раз в рамках таких приложений, как KDbg и DDD (Data Dispaly Debugger), но он не был идеальным по той причине, что иногда результаты форматировались для удобства чтения человеком, причем в этих случаях отбрасывались подробности выполнения команды и делалась ставка на возможность человека мыслить в определенном контексте.

Для решения этой проблемы в GDB реализован альтернативный "пользовательский" интерфейс, известный как машинный интерфейс (Machine Interface или MI для краткости). По своей сути это еще один интерфейс командной строки, но и команды и результаты их выполнения в данном случае используют дополнительные синтаксические конструкции для явного указания их особенностей - каждый аргумент помещен в кавычки и сложные выводимые структуры содержат разделители для подгрупп и имен параметров частей их компонентов. В дополнение команды машинного интерфейса могут использовать префиксы с идентификаторами последовательности, которые будут повторяться при выводе результатов выполнения команд для гарантии того, что результаты выполнения команд будут поставлены в соответствие правильным командам.

(gdb) step

buggy_function (arg1=45, arg2=92) at ex.c:232
232  result = positive_variable * arg1 + arg2;

4321-exec-step

4321^done,reason="end-stepping-range",
      frame={addr="0x00000000004004be",
             func="buggy_function",
             args=[{name="arg1",value="45"},
                   {name="arg2",value="92"}],
             file="ex.c",
             fullname="/home/sshebs/ex.c",
             line="232"}

Окружение разработки Eclipse [ecl12] является наиболее известным примером клиента машинного интерфейса.

Другие пользовательские интерфейсы

Дополнительные пользовательские интерфейсы представлены версией на основе tcl/tk с названием GDBtk или Insight, а также версией на основе curses с названием TUI, изначально реализованной компанией Hewlett-Packard. GDBtk является обычным многопанельным графическим интерфейсом, созданным с использованием библиотеки tk, в то время, как TUI является интерфейсом, созданным путем разделения областей текстового вывода на экране.

4.10. Процесс разработки

Мэйнтейнеры

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

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

Тестирование, тестирование

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

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

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

На конец 2011 года набор тестов состоит из 18,000 тестов, представленных тестами базовых функций, тестами, специфичными для языков программирования, тестами, специфичными для архитектур, а также тестами машинного интерфейса. Большая част этих тестов представлена обобщенными тестами, которые могут выполняться при любой конфигурации. Лицам, вносящим изменения в код GDB, следует выполнить тесты из набора по отношению к измененному исходному коду и убедиться в отсутствии регрессий, причем для каждой новой возможности должны реализоваться новые тесты. Однако, из-за того, что ни у кого нет доступа ко всем платформам, которые могут быть затронуты при внесении изменения в исходный код, очень редко удается достичь полного отсутствия неудачно завершенных тестов; наличие 10-20 неудачно завершенных тестов обычно вполне допустимо для создания копии исходного кода, предназначенной для непосредственной отладки, при этом для некоторых встраиваемых систем количество неудачно завершенных тестов может быть большим.

Продолжение статьи: Выученные уроки