отладка программ АСДиП ЯП ЯиМП 3GL 4GL 5GL технологии программирования

Отладка программ

ОперацииStep Into, Step Over иStep Out

Интересная проблема разработки WDBG
Итак, вы хотите написать собственный отладчик?
WDBG: что делать дальше?
Резюме.

Теперь, после описания точек прерывания и символьных машин, можно объяснить, как отладчики реализуют три замечательные операции — Step Into, Step Over и Step Out. Они не реализованы в WDBG, потому что я хотел сконцентрироваться на основных частях отладчика. Эти функции работают в рамках двух специальных представлений1 отлаживаемой программы, которые позволяют отслеживать текущую выполняемую строку или команду.

Все эти операции (Step Into, Step Over и Step Out) работают с одноразовыми точками прерывания, которые, как вы помните из предыдущих разделов, являются точками прерывания, сбрасываемыми отладчиком после того, как они срабатывают. При обсуждении пункта меню Debug Break (см. выше) был рассмотрен другой случай, в котором отладчик использует одноразовые точки прерывания для остановки обработки.

Операция Step Into работает по-разному, в зависимости от того, на каком уровне выполняется отладка: на исходном или на уровне дизассемблирования. При отладке на исходном уровне отладчик должен ориентироваться на одноразовые точки прерывания, потому что одна строка языка высокого уровня переводится в одну или большее количество строк языка ассемблера. При переводе CPU в пошаговый режим будет происходить пошаговое выполнение индивидуальных машинных команд, а не строк исходного кода.

На исходном уровне отладчик знает, на какой исходной строке вы находитесь. Когда выполняется команда отладчика Step Into, то для нахождения адреса следующей выполняемой строки отладчик использует символьную машину. Отладчик выполнит частичное дизассемблирование по адресу следующей строки, чтобы видеть, является ли эта строка командой вызова. Если строка — команда вызова, то отладчик установит одноразовую точку прерывания на первом же адресе функции, которую собирается вызывать подчиненный отладчик. Если адрес следующий строки — не команда вызова, то отладчик там и устанавливает точку прерывания one-shot. Затем отладчик разблокирует подчиненный отладчик, чтобы тот выполнился до только что установленной точки прерывания. Когда эта точка прерывания сработает, отладчик заменит код операции в точке ее размещения (в памяти) и освободит связанную с ней память. Если пользователь работает на уровне дизассемблирования, то реализовать Step Into намного легче, потому что отладчик будет просто переводить CPU в режим пошагового выполнения.

Операция Step Over похожа на Step Into в том, что отладчик должен отыскивать следующую строку в символьной машине и dsgjkyznm частичное дизассемблирование по адресу строки. Различие их в том, что для Step Over (если строка является вызовом) отладчик также будет устанавливать точку прерывания one-shot, но после инструкции вызова.

Операция Step Out, в некотором смысле, является самой простой из трех. Когда пользователь выбирает команду Step Out, отладчик проходит стек, чтобы найти адрес возврата для текущей функции и устанавливает по этому адресу точку прерывания one-shot.

Source view (представление в виде строк исходного кода) и disassembly view (представление в виде кодов дизассемблера в окне Disassembly). — Пер.

Обработка операций Step Into, Step Over и Step Out кажется довольно простой, но имеется одна особенность, которую следует рассмотреть. Что делать, если (в отладчике, создаваемом для управления этими операциями) уже установлены точки прерывания one-shot для этих операций, а перед ними срабатывает регулярная точка прерывания? Как разработчик отладчика, вы имеете две возможности. Первая — оставить только точки прерывания one-shot (чтобы только они и срабатывали). Другая возможность — удалять точки прерывания one-shot, когда отладчик уведомляет вас о том, что сработала регулярная точка прерывания. Отладчик Visual C++ использует последнюю возможность.

Интересная проблема разработки WDBG

Вообще у меня было мало неприятностей при разработке WDBG. Однако настало время обсудить одну, на мой взгляд, довольно интересную проблему. При работе с отладчиком Visual C++ окно Output показывает полные пути к загруженным программным модулям. Поскольку требовалось снабдить WDBG максимальным набором функциональных возможностей, в нем продублирована эта функция отладчика Visual C++. Но сделать это оказалось непросто.

Приведенное ниже определение структуры LOAD_DLL_DEBUG_INFO (она передается в отладчик при получении уведомлений LOAD_DLL_DEBUG_EVENT) содержит поле ipimageName, которое, по всей вероятности, должно хранить имя загружаемого модуля. Это так и есть, но ни одна из операционных систем Win32 никогда правильно не заполняет это поле при его считывании в программу.

typedef struct _LOAD_DLL_DEBUG_INFO

{

HANDLE hFile;

LPVOID IpBaseOfDll;

DWORD dwDebuglnfoFileOffset;

DWORD nDebuglnfoSize;

LPVOID IpimageName;

WORD fUnicode;

} LOAD_DLL_DEBUG_INFO;

Поскольку при получении уведомления LOAD_DLL_DEBUG_EVENT, образно говоря, модуль загружается в символьную машину DBGHELP.DLL, то мне казалось, что после загрузки модуля (в память) легко можно отыскать его полное имя. API-функция SymGetModuieinfo получает (через соответствующий параметр) показанную ниже структуру IMAGEHLP_MODULE, где имеется место для полного имени модуля (см. поле ModuleName[32]).

На самом деле все, по-видимому, наоборот: это символьная машина загружает символьную информацию модуля в соответствующий символьный файл (в данном случае — в DBG-файл). — Пер

typedef struct _IMAGEHLP_MODULE {

DWORD SizeOfStruct;

DWORD BaseOfImage;

DWORD ImageSize;

DWORD TimeDateStamp;

DWORD Checksum;

DWORD NumSyms;

SYM_TYPE SymType;

CHAR ModuleName[32];

CHAR ImageName[256] ;

CHAR LoadedlmageName[256];

} IMAGEHLP_MODULE, *PIMAGEHLP_MODULE;

Странная вещь: когда функция SymGetModuieinfo возвращает символьную информацию модуля, то вместо имени модуля либо возвращается имя символьного DBG-файла, либо ничего не возвращается (т. е. имя модуля в возвращаемой информации полностью пропускается). Такое поведение может показаться удивительным, но только на первый взгляд. Когда была получена • структура LOAD_DLL_DEBUG_INFO, ее первый член (типа hFile) был правильным, и тогда была вызвана функция SymLoadModuie с дескриптором того же типа (hFile). Поскольку я никогда не загружал в символьную машину DBGHELP.DLL полное имя файла, она просто заглядывала в открытый файл, обозначенный дескриптором hFile, находила в нем отладочную информацию и считывала ее. У символьной машины никогда не было необходимости знать полное имя файла.

Получить же требовалось полное имя загруженного модуля. Сначала я думал, что мог бы использовать сам дескриптор файла, чтобы получить доступ к экспортной секции модуля и сообщить найденное там имя модуля. Кроме того, модуль мог быть переименован, и его имя в экспортной секции было бы неправильным. Это мог быть ЕХЕ- или DLL-модуль, не содержащий списка экспортируемых модулей. И даже если бы как-то удалось найти правильное имя модуля, его полное имя (путь) было бы недоступно.

Затем я предположил, что где-то должна быть API-функция, которая будет получать (через аргумент вызова) значение дескриптора файла и возвращать полное имя открытого файла. Обнаружив, что в библиотеках операционной системы такой функции нет, я проверил несколько недокументированных значений, которые работали, но не полностью. Тогда я начал поиск с помощью функций из набора Tool Help и файла PSAPI.DLL, потому что оба этих средства сообщают информацию о модулях, загруженных в процесс. Функции Tool Help в Windows 98 работали нормально, в Windows NT 4 происходил сбой функций PSAPI.DLL, а в Windows 2000 функции Tool Help тяжело подвешивали отладчик. Сами функции Tool Help не были испорчены, но они пробуют стартовать новый поток в адресном пространстве подчиненного отладчика с помощью вызова CreateRemoteThread. Поскольку подчиненный отладчик был полностью остановлен в WDBG, функции Tool Help будут висеть, пока подчиненный отладчик повторно не стартует. После переключения на PSAPI.DLL в Windows 2000 вместо зависания происходил сбой функций Tool Help, как это было в Windows NT 4.

Используя подход к решению проблем, который был намечен еще в главе 1, я приступил к формулировке некоторой гипотезы, пытающейся объяснить проблему. Внимательное изучение функции GetModuleFilenameEx из PSAPI.DLL помогло понять, почему она не работала, когда я ее вызывал. Уведомление LOAD_DLL_DEBUG_EVENT сообщало мне, что DLL только собиралась загружаться в адресное пространство, а не то что DLL уже загружена. Поскольку память не была Отображена для хранения DLL, функция GetModuleFilenameEx из PSAPI.DLL терпела неудачу. Когда я выполнял пошаговый проход памяти этой функции на уровне языка ассемблера, то казалось, что она выглядит как список отображенной памяти, который операционная система поддерживает для каждого процесса.

Локализовав источник проблемы, нужно было только выяснить, когда операционная система полностью отображала модуль в памяти. Вероятно, можно было предпринять чрезвычайные меры, чтобы получить эту информацию, например, выполнив обратную разработку загрузчика образа в NTDLL.DLL и установив там точку прерывания. К счастью, нашлось немного более простое решение, которое не вызывало остановов на каждом релизе пакета обслуживания операционной системы. Оказалось, что загрузочную информацию модуля нужно просто поставить в очередь и время от времени проверять ее. pulseModuieNotification — это авторская функция, которая управляет деталями проверки загрузочной информации модуля; ее реализацию (исходный код) можно найти в файле MODULENOTIFICATION.CPP на сопровождающем компакт-диске. Если вы просмотрите исходный код функции DebugThread в DEBUGTHREAD.CPP на сопровождающем компакт-диске, то увидите, что функция PulseModuieNotification вызывается на каждом шаге цикла отладки, и каждый раз, когда завершается интервал ожидания (тайм-аут) функции WaitForDebugEvent.

Общий вопрос отладки

Почему я не могу входить в системные функции или устанавливать точки прерывания в системной памяти Windows 98?

Если вы когда-нибудь пробовали во время отладки входить внутрь (step into) некоторых системных функций операционной системы Windows 98, то могли убедиться, что отладчик не позволяет это делать. С другой стороны, Windows 2000 позволяет входить в любую точку процесса пользовательского режима. Дело в том, что Windows 2000 реализует "копирование-при-записи" во всей памяти, тогда как Windows 98 делает это только для адресов ниже 2 Гбайт.

Напомним, что "копирование-при-записи" позволяет процессам иметь свои собственные частные копии страниц отображенной памяти, когда они (процессы) или отладчик пишут на странице. В Windows 98 все процессы разделяют адресное пространство над 2 Гбайт. Поскольку Windows 98 не реализует "копирование-при-записи" для этих адресов, то если бы Windows 98 разрешала вам установить точку прерывания в разделяемой памяти, первый же процесс, который выполнил бы этот адрес, вызвал бы исключение точки прерывания. Поскольку этот процесс, вероятно, не выполняется под отладчиком, то он закончился бы с исключением точки прерывания. Хотя некоторые системные DLL, такие как сомсть32. DLL, загружаются ниже 2 Гбайт, главные системные DLL, такие как KERNEL32.DLL и USER32.DLL, загружаются выше 2 Гбайт. Это означает, что если у вас нет корневого отладчика, выполняющегося в Windows 98, то вы не можете входить в них с отладчиком пользовательского режима.

Итак, вы хотите написать собственный отладчик?

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

Первый шаг, который нужно сделать после рассмотрения WDBG, — получить превосходную книгу (Джонатан Розенберг "Как работают отладчики"). Хотя там не представлен исходный код отладчика, это — замечательное введение и обсуждение реальных проблем, с которыми программист столкнется при написании отладчика.

Необходимо детально познакомиться с форматом РЕ и конкретным CPU, на котором вы работаете. Сопровождающий компакт-диск содержит PECOFF.DOC, самую последнюю спецификацию РЕ-файлов от Microsoft. Подробнее можно изучать CPU по руководствам Intel CPU, доступным на www.intel.com.

Прежде чем заняться полным отладчиком, вы должны, вероятно, написать дизассемблер. Написание дизассемблера позволит не только подробнее изучить CPU, но и получить код, который можно будет использовать в отладчике. Дизассемблер в WDBG — это код "только-для-чтения" (read-only). Другими словами, только разработчик, который его написал, может его читать. Стремитесь делать ваш дизассемблер расширяемым и удобным для сопровождения. Я написал в прошлом довольно много программ на языке ассемблера, но действительно изучил язык ассемблера, только создав собственный дизассемблер.

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

Как уже говорилось, символьная машина DBGHELP.DLL достаточна для некоторых превосходных вспомогательных отладочных утилит, но не достаточна для реального отладчика. Вы можете всегда заняться обратной разработкой формата PDB-файлов, а мы все можем надеяться, что Microsoft когда-нибудь откроет доступ к PDB-файлам.

WDBG: что делать дальше?

После установки отладчик WDBG работает так, как было задумано. Однако его можно улучшить по многим направлениям. Ниже перечислены некоторые идеи усовершенствования WDBG. Если вы займетесь расширением WDBG, сообщите мне об этом. Кроме того, как уже говорилось в главе!, замечательной иллюстрацией профессиональных способностей программиста являются примеры собственного кода (весьма полезные, скажем, и для рабочих интервью). Если вы добавляете какое-нибудь существенное свойство к WDBG, то нужно показать это!

Можно заняться интерфейсом пользователя (UI) WDBG-отладчика. Первое усовершенствование, которое можно осуществить — улучшить реализацию этого интерфейса. Интерфейс уже содержит всю необходимую информацию; вы должны только спроектировать лучшие способы ее представления.
Сам WDBG поддерживает только простые, позиционные точки прерывания (location breakpoints). С помощью BREAKPOINT.H и BREAKPOINT.CPP можно добавить интересные дополнительные виды точек прерывания, такие как точки прерывания со счетчиком пропусков (skip count breakpoints) или точки прерывания выражений (expression breakpoints), для которых прерывание происходит, только если помеченное ими выражение истинно. Удостоверьтесь, что вы получаете новые точки прерывания с помощью функции CLocationBp (благодаря которой вы получаете се-\риализованный код и не должны ничего изменять в WDBG).
Вы должны быть способны без больших усилий расширить WDBG, чтобы поддержать отладку множественных процессов (multiple process debug->ging). Большинство интерфейсов построены для работы по схеме идентификации процесса, так что нужно только проследить, с каким процессом вы работаете во время уведомления об отладке.
Интерфейс WDBG построен так, чтобы позволить быстро перейти к удаленной отладке и различным CPU, оставив работу главной части интерфейса примерно такой же. Напишите динамические библиотеки удаленной отладки и расширьте WDBG так, чтобы позволить пользователю выбирать, где выполнять отладку: на местной или на удаленной машине.
Наконец, чтобы сделать WDBG-отладчик действительно полезным, вы всегда можете написать лучший дизассемблер и символьную машину для отладочных символов формата С7!

Резюме

В этой главе приведен краткий обзор механизмов функционирования отладчиков. Изучая различные инструментальные средства, можно существенно улучшить их использование. Здесь был представлен Win32 Debugging API (отладочный API 32-разрядных операционных систем Windows) и некоторые поддерживающие системы, такие, например, как символьные машины. Вы также узнали о существовании некоторых других отладчиков (кроме отладчика Visual C++). Наконец, приведен пример полного отладчика — WDBG, который хорошо иллюстрирует работу отладчика.

Думаю, что, внимательно просмотрев код WDBG, вы согласитесь, что отладчики выполняют такую же кропотливую работу с данными, как и любые серьезные программы. Самые большие трудности, которые нужно преодолеть при написании отладчика для Win32, заключаются в том, что существующие символьные машины обрабатывают только общие (public) функции, глобальные переменные и строки исходных и двоичных файлов. Без локальных переменных, параметров и типов трудно сделать отладчик почти таким же всесторонним, как отладчик Visual C++ или WinDBG.

отладка программ АСДиП ЯП ЯиМП 3GL 4GL 5GL технологии программирования

Знаете ли Вы, что диаграмма компонентов, Component diagram - это метод объектно-ориентированного проектирования, описывающий особенности физического представления системы. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, устанавливая зависимости между компонентами.

НОВОСТИ ФОРУМА

Рыцари теории эфира