Окно слежения за переменными. Окно открывается через View/Watches. Щелкнув правой кнопкой мыши, мы можем по желанию добавить в окно переменные, за значением которых мы хотим наблюдать. При пошаговом выполнении программы, либо при выполнении с точками останова можно на каждом этапе контролировать значение переменных.

Окно стека. Показывает текущее состояние стека. Причем первая вызванная функция будет находиться на дне стека.

Окно точек останова. Здесь содержится информация обо всех установленных в программе точках останова. Здесь же можно добавить или установить точки останова.

Окно регистрации (Log). В нем хранится информация о происходящих в отладчике событиях.

Окно переменных. Отображает все переменные, доступные в данном месте.

Окно файлов. В этом окне можно просмотреть двоичный файл и исправить его при необходимости.

Окно отображения памяти. Дает возможность построчного просмотра памяти.

Окно сопроцессора. Данное окно отображает текущее состояние сопроцессора.

Окно истории выполнения (Execution History). Окно содержит историю выполнения программы.

Окно иерархии (Hierarchy). Выводит на дисплей иерархическое дерево для всех объектов и всех типах классов, используемых в текущем модуле. Пример окна, отображающего иерархию классов объектов, см. на Рис. 4.3.3.

Рис. 4.3.3. Пример окна Turbo Debugger, отображающего иерархию классов.

Окно потоков. Данное окно содержит информацию обо всех потоках, работающих в данный момент в программе.

Окно сообщений. С помощью данного окна можно отслеживать все сообщения, получаемые указанным окном. На Рис. 4.3.4 представлен пример использования окна сообщений. Можно выделить класс отслеживаемых сообщений или задать единичные сообщения. Кроме отслеживания, можно задать и другую реакцию — прервать выполнение, т.е. установить точку останова на определенное сообщение.

Рис. 4.3.4. Пример содержимого окна сообщений

Окно буфера обмена. С помощью данного окна можно следить за содержимым буфера обмена при выполнении программы.

II

Поговорим теперь об отладке программ, написанных на языке высокого уровня. Если при трансляции в исполняемом модуле была сохранена отладочная информация, то Turbo Debugger будет работать и с языком высокого уровня. Рассмотрим, например, простую консольную программу, демонстрирующую пузырьковую сортировку. Программа располагается на Рис. 4.3.6.

Puc. 4.3.5. Программа, расположенная на Рис. 4.3.6 в окне отладчика.

#include <windows.h>
#include <stdio.h>
void sort(DWORD a[], DWORD );
void main()
{
 DWORD a[10];
 DWORD j,p,k,r;
 randomize();
 for(j=0; j<10; j++) a[j]=random(10) ;
// сортировка
 for(k=9; k>l; k--)
 {
 r=0;
 for(j=0; j<k; j++)
 {
 if(a[j]>a[j+1]){ p=a[j+1] ;
 a[j+1]=a[j] ;
 a[j]=p; r=1;
 };
 }
 if(r==0) break;
 }
 for(j=0; j<10; j++) printf("%lu\n",a[j]);
 ExitProcess(0);
}

Рис. 4.3.6. Пример простой консольной программы.

На Рис. 4.3.5 показано окно отладчика Turbo Debugger с данной программой. В нижней части рисунка расположено окно Watches. В этом окне отслеживается значение элементов массива а[]. Обратившись к окну CPU, можно увидеть, как алгоритм пузырьковой сортировки, реализованный на языке Си, преобразуется в ассемблерный код.

III

Основной целью отладчика Turbo Debugger является отладка программы, имеющей отладочную информацию. Дело в том, что хотя отладчик и дизассемблирует программу, и мы можем видеть дизассемблированный код в окне CPU, такие дизассемблеры, как W32Dasm и IDA Pro намного превосходят в этой части Turbo Debugger. Отладчик же Ice, работая в нулевом кольце, также более удобен для анализа исполняемых модулей. Отладчик Turbo Debugger занимает свою нишу в отладке, но здесь он незаменим и очень удобен. В данном разделе мы намерены рассмотреть некоторые вопросы методики отладки.

Вообще процесс отладки можно разделить на четыре этапа:

1. Обнаружение ошибки. Обнаружение ошибок в программе связано с тестированием программы и ее эксплуатацией.
2. Поиск ее местонахождения. Данный этап часто оказывается самым трудоемким, и именно здесь может пригодиться использование отладчика. Профессиональные программисты знают, что в сложных алгоритмах найти ошибку путем простого анализа текста программы бывает очень сложно. Можно, конечно, выводить промежуточные результаты, но для этого может понадобиться слишком много таких выводов. Хороший отладчик в этом случае незаменим, поскольку может позволить отслеживать значение переменных на каждом шаге.
3. Определение причины ошибки. Отбрасывая тот случай, когда причиной ошибки является неправильный алгоритм, рассмотрим типичные ассемблерные ошибки.
   1. Ошибка в порядке следования операндов. Например, MOV EAX,EBX вместо MOV EBX,EAX.
   2. При использовании рекурсивных алгоритмов или слишком большой вложенности вызовов процедур может быть исчерпан стек.
   3. При вызове процедур может быть испорчено содержимое того или иного регистра.
   4. Неосвобождение стека при выходе из процедуры.
   5. Неправильное использование условных переходов - JA вместо JNA и т.п.
   6. Часто при организации циклических алгоритмов программисты ошибаются относительно последних значений переменных.
   7. Неправильная установка флага направления.
   8. Ошибка при определении границ переменных и массивов. Эти ошибки часто приводят к тому, что портится содержимое и других переменных.
   9. Неправильное преобразование из одного типа операнда к другому. Например, после загрузки MOV AL,BL используется EAX и забывается об обнулении старших байтов регистра EAX.
4. Исправление ошибки. Если найденная ошибка проста и очевидна для Вас, то исправить ее не составит большого труда. Кстати, как Вы, наверное, уже поняли, Turbo Debugger не позволяет исправлять исполняемые модули. Но случаются и ситуации, когда очевидно, что данный участок программы (или процедура) выдает ошибочное значение, а на то, чтобы найти ошибку, у Вас не хватает времени - участок достаточно сложен. Иногда неправильное значение выходной информации возникает, лишь при редком сочетании входных параметров. В этом случае может быть применен простой прием: между указанным участком и остальной частью программы вставляется несколько строк, проверяющих выходную информацию и исправляющих ее, если нужно. Такой прием часто оказывается незаменим при доработке чужой программы очень большого объема, когда понять логику чужого алгоритма (да еще содержащего ошибку) бывает просто невозможно.