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

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

Отладка средствами языка ассемблера х86
и окна Disassembly отладчика Visual C++

ОкноDisassembly

Навигация
Просмотр параметров в стеке
КомандаSet Next Statement
ОкнаMemory иDisassembly
Советы и специальные приемы
Endians.
Код мусора
Регистры и окноWatch
Изучайте ASM-файлы
Резюме

Теперь, немного познакомившись с языком ассемблера, рассмотрим свойства окна Disassembly отладчика Visual C++, облегчающие выполнение отладочных работ, и способы уменьшения времени, проводимого в окне Disassembly.

Первый путь для достижения определенной позиции в подчиненном отладчике — через диалоговое окно Go To, открываемое командой Go To меню Edit или нажатием клавиш <Ctrl>+<G>. Если адрес перехода известен, то его можно ввести в поле Enter address expression и переходить в нужное место в коде прямо по этому адресу. Диалоговое окно Go To поддерживает также интерпретацию символов и контекстной информации, поэтому можно переходить к областям памяти, даже не зная точного адреса.

Например, если имеются символы, загруженные для KERNEL32.DLL, и требуется перейти к коду функции LoadLibrary в окне Disassembly, то для этого следует ввести в диалоговом окне Go То строку

{,, kerne!32}_LoadLibraryA@4

Весьма полезна еще одна известная возможность, которую поддерживает окно Disassembly — буксировка мышью ("drag-and-drop"). Если вы работаете через секцию языка ассемблера, и нужно быстро проверить, где в памяти выполняется операция, то можно выделить адрес и перетащить его. После отпускания кнопки мыши окно Disassembly автоматически переходит к этому адресу.

Для того чтобы вернуться обратно туда, где находится указатель инструкции, просто сделайте правый щелчок мышью в окне Disassembly и введите команду Show Next Statement. Эта команда также доступна в окнах исходного кода.

Просмотр параметров в стеке

В главе 5 показано, как устанавливать точки прерывания на системных и экспортируемых функциях. Одна из главных причин для установки точек прерывания на этих функциях — необходимость просматривать параметры, которые передаются в данную функцию.

С тех пор как Visual Basic 5 позволил получать "родной" код (native code), я хотел посмотреть, как работает "родная" компиляция. Каталог Visual Basic включал файлы LINK.EXE и С2.ЕХЕ. Эти две программы являются также частью Visual C++, и было любопытно посмотреть, как их использует Visual Basic, как вообще работает компиляция. Как можно понять из названия, LINK.EXE связывает объектные файлы и производит выполняемый двоичный файл. С2.ЕХЕ довольно сложен. В системе Visual C++ файл С2.ЕХЕ — это генератор кода, который производит машинный код.

Из интегрированной среды разработки (IDE) Visual C++ я открыл VB6.EXE как программу для отладки. Поскольку были загружены символы, нужно было установить точку прерывания на {,, kernel32}_CreateProcessA@40. Запустив Visual Basic, я создал простой проект, установил свойства 'Проекта для создания "родного" кода и выбрал команду File|Make из IDE Visual Basic. Точка прерывания на _CreateProcessA@4о,обеспечивает управление отладчика при запуске или С2.ЕХЕ, или LINK.EXE.

В Windows 2000 RC2 точка прерывания на _CreateProcessA@40 останавливает отладчик на адресе 0x77E8D7E6, когда инструкция, подлежащая выполнению (PUSH EBP), устанавливает стандартный кадр стека. Поскольку точка останова находится на первой инструкции функции createProcess, вершина стека содержит параметры и адрес возврата. Затем при помощи команды View|Debug Wmdows|Memory я открыл окно Memory и ввел в поле Address строку ESP, которая является именем регистра указателя стека, чтобы просмотреть содержимое стека.

По умолчанию данные в окне Memory отображаются в байтовом формате. Поиск при этом может быть довольно утомительным. Щелчок правой кнопкой мыши в окне Memory позволяет выбрать формат: byte, short hex (2 байта или WORD) и long hex (4 байта или DWORD).

На рис. 6.4 показан стек в окне Memory отладчика в начале точки прерывания на функции CreateProcess. Первое значение — адрес возврата для инструкции OxFB6B3F6J 10 следующих — Параметры фуyrwbb CreateProcess (СМ. табл. 6.5). Параметры функции CreateProcess занимают 40 байт, а каждый параметр имеет длину 4 байта. Стек растет от старших адресов памяти к младшим, а параметры помещаются в стек справа налево, поэтому параметры появляются в окне Memory в том же порядке, как в определении функции.

Рис. 6.4. Стек в окне Memory отладчика Visual C++

Просматривать индивидуальные значения первых двух параметров можно двумя способами. Первый состоит в том, чтобы использовать окно Memory, переключая его в байтовый формат и рассматривая конкретный адрес. Второй, более легкий способ, состоит в том, чтобы буксировать (мышью) адрес, который требуется рассмотреть, в окно Watch. В окне Watch для просмотра адреса следует использовать оператор приведения типов. Например, чтобы просмотреть параметр ipAppiicationName в примере, надо поместить в окно Watch строку <char*)Oxooi2EAC4. Работает любой способ просмотра, и оба должны показать следующие значения:

0х0012ЕАС4 "c:\vb\C2.EXE"

0х0012ЕВС4 "С@ -11 "e:\temp\VB815574

-f "c:\junk\vb\Forml.frm _W 3 _Gy _G5

-GS4096 _dos _Z1

-Fo"c:\junk\vb\Forml.OBJ" _Zi _QIfdiv

-ML _basic"

Таблица 6.5. Параметры, которые VB6.EXE передает В функцию CreateProcess

Значение	Тип	Параметр
0x001 2ЕАС4	LPCTSTR	IpApplicationName

0x0012EBC4	LPTSTR	IpCommandLine
0x00000000	LPSECURITY_ATTRIBUTES	IpProcessAttributes
0x00000000	LPSECURITY_ATTRIBUTES	IpThreadAttributes
0x00000001	BOOL	blnheritHandles
0x08000000	DWORD	dwCreationFlags
0x00000000	LPVOID	IpEnvi r onment
0x00000000	LPCTSTR	IpCurrentDirectory
0x001 2EA3C	LPSTARTUPINFO	IpStartupInfo
0x001 2EC60	LPPROCESS_INFORMATION	IpProcessInformation

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

Команда Set Next Statement

Команда Set Next Statement окна Disassembly доступна в контекстном меню (открываемом правым щелчком мыши) и позволяет изменить EIP (регистр указателя инструкций), при помощи перевода указателя на следующую позицию исполнения. В окнах с исходными кодами команда Set Next Statement допускает некоторую "небрежность", но следует быть очень осторожным с этой командой в окне Disassembly.

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

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

00401032 PUSH EBP

00401033 MOV EBP , ESP

00401035 PUSH 404410h

0040103А CALL 00401005h

0040103F ADD ESP , 4

00401042 POP EBP

00401043 RET

Дважды проходя через дизассемблирование, необходимо удостовериться, что при выполнении инструкции ADD по адресу 0x0040103F не нарушает баланс стека. Как было показано ранее при обсуждении различных соглашений о вызовах, данный фрагмент ассемблерного кода показывает обращение к _cded-функции (потому что инструкция ADD расположена прямо после ее вызова). Чтобы повторно выполнять функцию, следует установить указатель инструкций на 0x00401035, гарантируя, что операция PUSH выполнится должным образом.

Окна Memory и Disassembly

Окна Memory и Disassembly имеют симбиозные отношения. Пытаясь определить, что делает последовательность операций языка ассемблера в окне Disassembly, надо держать окно Memory открытым, чтобы можно было видеть и адреса, и значения. Инструкции языка ассемблера работают в памяти, а память воздействует на выполнение этих инструкций. Окна Disassembly и Memory вместе позволяют наблюдать динамику этих взаимоотношений. Само по себе, окно Memory — просто море чисел, особенно когда происходит аварийный отказ. Однако, комбинируя эти два окна, можно начать вычисления, связанные некоторыми неприятными проблемами аварийных отказов. Совместное использование этих окон наиболее важно при отладке оптимизированного кода, когда прохождение стека отладчика затруднено. Чтобы разрешить аварийную ситуацию, необходимо пройти стек вручную. На первом этапе прохождения стека нужно знать, по каким адресам памяти загружены ваши двоичные файлы. В отладчике Visual C++ 6 добавлено диалоговое окно Module List, отображающее все двоичные файлы, загруженные вашей программой. Оно показывает также имя модуля, путь к модулю в дереве каталогов, порядок загрузки и, самое важное, диапазон адресов загрузки модуля. Поскольку это окно является модальным, лучше записать имена модулей и их загрузочные адреса, потому что эта информация понадобится в будущем неоднократно. Сравнивая элементы стека со списком диапазонов адресов, можно получить некоторое представление о том, какие элементы адресованы в ваших модулях.

Просмотрев диапазоны адресов загрузки, откройте окна Memory и Disassembly. В окне Memory введите в поле Address регистр стека ESP и покажите значения в формате двойного слова, щелкая правой кнопкой мыши в пределах окна и выбирая команду Long Hex Format в контекстном меню. Используя либо свой список адресов загрузки, либо диалоговое окно Module List, начните просмотр чисел в окне Memory слева направо и сверху вниз.

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

Если регистр ESP не содержит ничего, что напоминало бы адрес модуля, выведите дамп регистра ЕВР в окно Memory и выполните те же действия. Освоившись с языком ассемблера, вы сможете просматривать дизассемблерный код, окружающий адрес аварийного останова. Изучение "криминальной" аварийной ситуации позволит вам понять, где бы мог быть расположен адрес возврата — в ESP или в ЕВР.

Поговорим немного сначала о достоинствах, а затем и о недостатках окна Memory. Во-первых, окно Memory — единственное место, где можно просматривать символьные строки, превышающие 255 знаков. Кроме того, окно Memory позволяет просматривать любую переменную или участок памяти.

Теперь о недостатках. Первый состоит в том, что одновременно с отладчиком Visual C++ можно просматривать только один участок памяти, и это ограничение обойти нельзя. Во-вторых, отображаемые данные, которые вы просматриваете, могут резко перемещаться по экрану. Это случается главным образом при изменении формата памяти. Оказалось, что лучше всего выполнять правый щелчок мыши только на адресе, который необходимо видеть (в окне Memory) — и нигде больше. Очевидно, окно Memory запоминает то места, где оно показывает текущую строку адреса. Например, если строка текущего адреса — десятая от вершины окна, а пользователь вводит новый адрес в поле Address, то новый адрес будет отображен в десятой строке. Если при выполнении правого щелчка мыши в окне изменяется формат памяти, окно Memory перемещает строку текущего адреса к позиции правого щелчка, и результат может быть непредсказуемым.

История отладочной войны

Что может быть не так в функции GlobalUnlock?

Ведь она просто разыменовывает указатель.

Сражение

Отладка чрезвычайно неприятной аварийной ситуации, грозившей сорвать выпуск продукта, длилась почти месяц. Дублировать аварию не удавалось, и разработчики понятия не имели, в чем ее причина. Единственным ключом к разгадке было то, что аварийный сбой случался только после открытия диалогового окна Print и изменения некоторых ее установок. Аварийный останов происходил немного позже (после закрытия этого окна) в элементах управления независимых поставщиков. Аварийный стек вызовов указывал, что авария произошла в середине функции GlobalUnlock.

Результат

Во-первых, не было уверенности, что кто-то еще использует функции дескрип-торной памяти (handle-based memory) GlobalAlloc, GlobalLock, GlobalFree и

GlobalUnlock) в \Л/1п32-програм|»ировании. Однако после просмотра в коде дизассемблера сторонних управляющих элементов стало понятно, что их автор, очевидно, перенес их из 16-разрядной кодовой базы. Первая гипотеза состояла в том, что эти элементы неправильно взаимодействовали с API-функциями де-скрипторной памяти.

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

В некоторой точке после закрытия диалогового окна Print, мы заметили, что стартовавшая функция GlobalAlloc возвращала значения дескриптора, которые завершались нечетными цифрами, например, 5. Поскольку дескрипторная память в Win32 нуждается в разыменовании указателя, чтобы преобразовать дескриптор в значения памяти, я сразу же понял, что наткнулся на критическую ситуацию. Каждое распределение памяти в Win32 должно заканчиваться шест-надцатеричными цифрами 0, 4, 8 или С, потому что все указатели должны быть выровнены на двойное слово. Значения же дескрипторов, выходящие из GlobalAlloc, были явно (и довольно значительно) искажены.

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

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

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

Хотя при начальном чтении код выглядел безупречно, я просматривал каждую строку в обратном порядке и перепроверял ее по документации MSDN. Через 10 минут ошибка была найдена. Команда сохраняла структуру данных PRINTDLG, используемую для инициализации диалогового окна Print, с помощью API-функции PrintDlg. Третье поле в этой структуре — hDevMode — является значением дескрипторной памяти, которую выделяет диалоговое окно Print. Ошибка состояла в том, что разработчики использовали это значение памяти как регулярный указатель и должным образом не разыменовывали дескриптор или вызывали функцию GlobalLock для дескриптора. Изменяя значения в структуре DEVMODE, на самом деле они выполняли запись в глобальную таблицу дескрипторов процесса. Эта таблица является участком памяти, в котором хранятся все распределения динамической памяти дескрипторов. При случайной записи в глобальную таблицу дескрипторов обращение к GlobalAlloc использует неправильные смещения, а значения, вычисленные по такой таблице, приводили к тому, что функция GlobalAlloc возвращала некорректные указатели.

Уроки

Урок первый — нужно тщательно читать документацию. Если в документации говорится, что структура данных есть "перемещаемый глобальный объект памяти", то память предназначена для дескрипторов, и необходимо должным образом разыменовывать этот дескриптор памяти или использовать на нем функцию GlobalLock. Хотя Windows 3.1 сильно устарела, некоторые 16-разрядные компоненты все еще входят в Win32 API, и следует обращать на них внимание.

Урок второй — глобальная таблица дескрипторов хранится в перезаписываемой памяти. Лично я считаю, что такая важная структура операционной системы должна храниться в памяти "только-для-чтения". Почему Microsoft не защитил эту память? Могу предположить, что дело в следующем. Технически память дескрипторов используется только для обратной совместимости, и 32-разрядные Windows-приложения должны бы были использовать специфические для Win32 типы памяти. Защита глобальной таблицы дескрипторов потребовала бы двух переключений контекста (из режима пользователя в режим ядра) на каждом вызове функции дескрипторной памяти. Поскольку эти контекстные переключения очень дороги (в смысле времени их обработки), можно понять, почему Microsoft не защитил глобальную таблицу дескрипторов от записи.

Урок последний — мы потратили слишком много времени, сосредоточившись на стороннем элементе управления. Всего мне потребовалось около семи часов, чтобы найти ошибку. Однако тот факт, что ошибка могла дублироваться только при открытии диалогового окна Print, которая пришла из кода приложения, должен был предупредить меня, что проблема была "ближе к дому" (а не где-то на стороне).

Советы и специальные приемы

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

Endians

Термин "Endianness" описывает свойство CPU, которое определяет порядок хранения частей многобайтовых данных в памяти. Для Intel CPU это свойство обозначают как "Little Endian", что означает, что младший байт (т. е. конец) многобайтового значения хранится в памяти первым. Например, значение 0x1234 хранится в памяти как 0x34 0x12. Важно помнить об этом при просмотре памяти в отладчике. Чтобы получить правильные значения, нужно выполнить преобразование самостоятельно. Если окно Memory используется для просмотра одного из узлов связного списка, и следующим значением указателя является 0x12345678, то в окне это значение будет показано в байтовом формате как 0x78 0x56 0x34 0x12.

Для любопытных: термин "Endian" пришел из "Путешествий Гулливера" Джонатана Свифта, а компьютерное его значение — из RFC-запроса Дэнни Коена (Danny Cohen, 1980) относительно упорядочивания байтов. Полную историю можно найти в статье Дэнни Коена по адресу:

http://www.op.net/docs/RFCs/ien-137.

RFC — Request for Comments (Запросы на комментарии и предложения). — Пер

Код мусора

Когда в результате аварийного останова вы оказываетесь в окне Disassembly, необходимо определить, действительно ли там отображается реальный код (это иногда довольно трудно). Вот некоторые советы:

оказалось, что для просмотра кодов инструкций ассемблера полезно включение режима Code Bytes (в контекстном меню окна Disassembly);
если в окне Disassembly отображается ряд идентичных инструкций ADD BYTE PTR [EAX], AL, это не есть правильный код ассемблера. Вы видите ряд нулей;
если отображаются символы, но добавленные к ним смещения — очень большие числа, в общем случае превосходящие 0x1000, то вы, вероятно, вне секции кода. Однако очень большие числа могут также означать, что отлаживается модуль, который не содержит доступных частных (private) символов;
если вы видите группу инструкций, которые не описаны в этой главе, значит вы, вероятно, видите данные;
если дизассемблер Visual C++ не может дизассемблировать инструкцию, то в качестве кода операции он показывает "???".

Регистры и окно Watch

Окно Watch отладчика Visual C++ "знает", как нужно декодировать мнемонику всех регистров в их значения. Поэтому, просматривая, например, инструкцию, манипулирующую со строками, можно ввести в окно Watch строку (char*)@EDi, чтобы просматривать данные в формате, который легче читать.

Изучайте ASM-файлы

Чтобы увидеть смешанный код — исходный и ассемблера, нужно с помощью Visual C++ сгенерировать ассемблерные листинги для исходных файлов. Если вы укажете ключ /FAS в редактируемое поле Project Options на вкладке C++ диалогового окна Project Settings, то компилятор сгенерирует ASM-файл для каждого исходного файла. Можно не генерировать ASM-файлы при каждом построении, но они могут быть поучительны, позволяя видеть генерируемый компилятором код. При наличии ASM-файлов не требуется каждый раз запускать приложение, когда возникает необходимость просмотреть программу в кодах языка ассемблера.

Сгенерированные файлы почти готовы для компиляции с помощью макроассемблера Microsoft (Microsoft Macro Assembler — MASM), но они могут быть довольно сложными для чтения. Многие файлы состоят из директив MASM, но главные части файлов показывают С-код вместе с кодом языка ассемблера под каждой С-конструкцией. После усвоения материала этой главы читатели не должны испытывать никаких проблем при чтении ASM-файлов.

Резюме

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

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

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

Знаете ли Вы, что событийно-управляемое программирование - это объектно-ориентированное программирование, при котором задаются реакции программы на различные события.

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

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

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

Отладка средствами языка ассемблера х86 и окна Disassembly отладчика Visual C++

ОкноDisassembly

Навигация

Отладка средствами языка ассемблера х86
и окна Disassembly отладчика Visual C++