2003 г

ОТЛАДКА СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ

Обзор

К.А. Костюхин, НИИСИ РАН

Содержание

1. Введение

1.1. Основные определения

Предметом настоящего обзора является отладка систем реального времени.

Под системой реального времени (СРВ) мы понимаем систему, в которой корректность функционирования зависит от соблюдения временных ограничений.

Существующие СРВ являются многозадачными. Многозадачность реализуется через многопроцессность*) и многопоточность.


Под процессом понимается держатель ресурсов (например, память, данные, дескрипторы открытых файлов), которые не разделяются с другими процессами. В рамках одного процесса выполняются один или несколько потоков. Они совместно используют ресурсы процесса.


Многопроцессность в СРВ имеет существенные недостатки, поскольку требует поддержки времени выполнения для доступа к памяти, и, следовательно, при переключении контекстов системе нужно выполнить дополнительные действия.

Многопоточность - это наиболее распространенный подход при проектировании систем реального времени, при котором СРВ представляет собой один процесс, в рамках которого запущено несколько потоков.

Недостатком многопоточности является возможность модификации чужих данных какой-либо задачей (из-за отсутствия защиты). В связи с этим в СРВ представлены средства синхронизации, то есть средства, обеспечивающие задачам доступ к разделяемым ресурсам. К таким средствам относятся семафоры (бинарные и счетчики), мьютексы, очереди сообщений (см. [1],[3],[25]).

Структура СРВ приведена на рис.1, где прикладной код - это совокупность пользовательских потоков управления, ОСРВ - операционная система реального времени, обеспечивающая планирование, синхронизацию и взаимодействие пользовательских потоков управления.


Рис. 1. Структура системы реального времени

Будем называть распределенную систему распределенной системой реального времени (РСРВ), если корректность ее функционирования зависит также и от ограничений, накладываемых на время обмена между компонентами системы.

1.2. Особенности отладки в системах реального времени

Отладка в СРВ направлена на обнаружение и исправление ошибок в прикладном коде. Она является одним из этапов кросс-разработки, схему которой можно представить следующим образом. Разработка приложения ведется как минимум на двух машинах: инструментальной и целевой. На инструментальной платформе происходит написание исходного текста, компиляция и сборка. На целевой - загрузка приложения, его тестирование и отладка.

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

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

Второй способ - удаленная отладка (кросс-отладка). Кросс-отладка позволяет использовать ресурсы инструментальной системы при изучении поведения некоторого процесса в целевой системе.

Эффективность удаленной отладки зависит от типа связи инструментальной и целевой машин, а также от поддержки средств отладки со стороны целевой архитектуры.

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

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

Под мониторингом понимается сбор данных о задаче (значения регистров, переменных, и.т.д) или о системе в целом (стадии выполнения задач, происходящие события, и.т.д).

Осуществлять сбор данных помогает псевдо-агент (набор инструкций, встроенных в код задачи). Обычно его добавляют на этапе проектирования. Простой пример псевдо-агента - вызов assert, позволяющий вести диагностику работы задачи.

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

1.3. Ошибки в системах реального времени

Отмеченные выше методы отладки позволяют выявлять и устранять ошибки следующего характера:

  1. Ошибки в программном обеспечении, влекущие неправильное выполнение задачи (безотносительно времени). Обычные ошибки, обнаруживаемые средствами активной отладки. Эти средства будут рассмотрены в разделе 2.
  2. Ошибки в ОСРВ: ошибки планирования, синхронизации и связи.Для отладки, в этом случае, надо использовать один из способов мониторинга. Подробно средства мониторинга описаны в разделе 3.
  3. Логические ошибки, связанные с асинхронностью. Пример такого рода ошибок и способы их устранения будут приведены в разделе 4.
  4. Ошибки, связанные с тем, что данные задачи были изменены другой задачей. Локализацию ошибок лучше проводить, используя мониторинг, а именно: осуществлять периодический контроль целостности данных, временно запрещать другим задачам доступ к некоторым участкам кода или данных.

2. Средства активной отладки

2.1. Архитектура средств активной отладки

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

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

Общая структура активного кросс-отладчика приведена на рис.2.


Рис. 2. Активный кросс-отладчик

Рассмотрим протокол "менеджер-агент" на примере отладчика VxGDB (Wind River Systems, целевая система - VxWorks). Этот протокол базируется на RPC (Remote Procedure Call). Запросы менеджера можно классифицировать следующим образом:

  1. Запросы работы с модулями
    Сюда относятся запрос на загрузку модуля, запрос на получении информации о загрузочном файле и запрос на получение информации о символе.
  2. Запросы работы с задачами
    Это запросы на запуск, остановку и удаление задачи, на присоединение и отсоединение от запущенной задачи, на установку и удаление точки прерывания, на продолжение выполнения остановленной задачи.
  3. ptrace-запросы
    Агент отладки эмулирует функцию ptrace и передает ей соответствующие запросы на чтение и запись.
2.2. Отладочные действия

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

1) Предварительные действия отладчика

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

2) Прерывание выполнения задачи

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

3) Получение информации

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

4) Продолжение/изменение выполнения

Особенностью активной отладки является возможность изменения выполнения задачи.

2.3. Пользовательский интерфейс

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

Интерфейс отладчика состоит из:

1) Графический интерфейс

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

2) Режим командной строки

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

3) Команды представления данных

Приведем некоторые способы представления и хранения данных, реализация которых в значительной степени упрощает работу пользователя:

2.4. Интеграция со средствами разработки ПО

Обычно, программный продукт проходит стадии разработки, представленные на рис.3.


Рис. 3. Стадии разработки ПО

В [24] описан способ, позволяющий уменьшить общее время разработки программного продукта за счет объединения средств тестирования и отладки. Такую возможность предоставляет отладчик Pilot (Kvatro Telecom). Подобное совмещение обладает следующими преимуществами:

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

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

3. Средства мониторинга

3.1. Архитектура средств мониторинга

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

При мониторинге агенту отладки не нужно поддерживать прямой связи с псевдо-агентами, так как псевдо-агенты могут посылать собранные данные в буфер, где они будут накапливаться вместе с остальными данными.


Рис. 4. Архитектура отладчика, осуществляющего мониторинг
3.2. Отладочные действия

Отладочные действия при мониторинге можно разделить на следующие категории:

1) Сбор данных

Существует несколько способов сбора данных на целевой машине и передачи их менеджеру:

2) Анализ данных

Нас интересует следующая классификация видов анализа: