Отладка систем реального времени (стр. 3 из 5)
GDB в данном случае предоставляет следующие возможности:
Команда display. После остановки выполнения задачи (но не в случае, когда она завершилась) производится отображение данных, заданных в качестве аргументов этой команды.
Команда commands привязывает к точке прерывания, номер которой задан в качестве аргумента, набор действий, которые нужно реализовать отладчику при достижении этой точки прерывания.
2.4. Интеграция со средствами разработки ПО
Обычно, программный продукт проходит стадии разработки, представленные на рис.3.
Рис. 3. Стадии разработки ПОВ [24] описан способ, позволяющий уменьшить общее время разработки программного продукта за счет объединения средств тестирования и отладки. Такую возможность предоставляет отладчик Pilot (Kvatro Telecom). Подобное совмещение обладает следующими преимуществами:
сразу выявляются ошибки в тесте;
имеется возможность генерировать тесты в процессе отладки;
результаты теста сразу обрабатываются и в случае ошибки передаются отладчику, который интерактивно воспроизводит этот тест.
Средства поддержки отладки могут закладываться на стадии написания исходного текста и компиляции. Во время написания исходного текста в программный продукт может закладываться псевдо-агент - набор функций, осуществляющих некоторые отладочные действия.
Для отладки с использованием исходных текстов приложения, необходимо при компиляции генерировать дополнительную информацию, состоящую из описаний символов программы (переменные, функции, типы) и псевдо-символов, позволяющих отладчику определять адреса строк исходного текста, адреса секций, и.т.д.
3. Средства мониторинга
3.1. Архитектура средств мониторинга
Архитектура средств мониторинга в общем случае совпадает с архитектурой средств активной отладки, с той лишь разницей, что агенту отладки запрещено останавливать отлаживаемую задачу и модифицировать ее данные. Вообще, основное требование к средствам мониторинга - сбор данных с минимальным вмешательством в работу целевой системы. Для этого агенту отладки нужно как можно реже обращаться к менеджеру, то есть хранить полученные данные в некотором буфере и пересылать их по мере заполнения буфера. Кроме того, при пересылке данных можно производить их фильтрацию или сортировку в соответствие с некоторым критерием значимости.
При мониторинге агенту отладки не нужно поддерживать прямой связи с псевдо-агентами, так как псевдо-агенты могут посылать собранные данные в буфер, где они будут накапливаться вместе с остальными данными.
Рис. 4. Архитектура отладчика, осуществляющего мониторинг Отладочные действия при мониторинге можно разделить на следующие категории:
сбор данных;
анализ данных;
профилирование системы;
"посмертный" анализ.
1) Сбор данных
Существует несколько способов сбора данных на целевой машине и передачи их менеджеру:
Передавать данные на инструментальную сторону по мере их поступления.
Этот способ применяется при оперативной отладке.
Передавать данные в случае заполнения буфера.
Обычный способ сбора данных при мониторинге.
Сохранять данные на диске.
Таким способом можно получать данные для последующего анализа (конечно, лучше осуществлять сохранение данных с инструментальной машины, уже получив их).
Сбор данных может осуществляться однократно, циклически или непрерывно. При этом отладчик может совершать следующие действия:
начать сбор данных (указывается способ сбора, буфер или имя файла, период сбора, время между циклами или время завершения);
прервать сбор данных;
запланировать начало и/или конец сбора данных по времени, получению сигнала или произошедшему событию.
Данные могут представлять собой как информацию о задаче (содержимое регистров, стека, и.т.д), так и информацию о системе в целом (протокол произошедших событий, протокол выделения памяти).
Один из способов протоколирования событий заключается в том, что на функции, исполнение которых приводит к некоторому событию, ставится специального вида точка прерывания (eventpoint). Такой подход позволяет пользователю определять собственные события (как это сделано в WindView - Wind River Systems, целевая система VxWorks).
Теперь рассмотрим технологию сбора данных на примере StethoScope (Wind River Systems, целевая система VxWorks). При сборе данных о функции используется механизм вставки исполняемого кода перед и после вызова отлаживаемой функции. Его суть в том, что пользователь может задать функции, вызовы которых будут предварять и завершать исполнение требуемой процедуры. Этот механизм используется и в служебных целях, например при трассировке задачи. Реализовать его можно так: на первую инструкцию отлаживаемой функции ставится точка прерывания, обрабатываемая особым образом, а именно:
ставится точка прерывания на точку возврата из отлаживаемой функции;
передается управление функции, которая должна быть вызвана перед отлаживаемой (если такая определена);
запускается выполнение отлаживаемой функции.
Затем при обработке второй точки прерывания вызывается функция, реализующая некоторый набор завершающих действий.
При сборе информации о динамическом выделении памяти можно использовать такой подход (RTILib - Real-Time Innovations, целевая система VxWorks). Заменить функции выделения и освобождения памяти (malloc, calloc, realloc, free) на соответствующие функции, выполняющие, помимо работы с памятью, некоторые отладочные действия, а именно: маркировку границ выделенного блока и последующий контроль за ее сохранностью (так можно фиксировать выход за границы), установку флага доступа к блоку (для запрещения/разрешения обращения к этому блоку), сбор статистики по использованию памяти, протоколирование информации по выделенным блокам.
2) Анализ данных
Нас интересует следующая классификация видов анализа:
Анализ на инструментальной стороне.
Рассматриваемые средства отладки обеспечивают анализ не только данных, полученных во время текущего сеанса отладки, но и данных, полученных ранее и сохраненных на диске. Кроме того, при обработке данных фиксируется время их получения, а для событий - время, в которое они произошли.
Анализ на целевой стороне.
Некоторые данные требуют анализа на целевой стороне. Например, контроль работы задач с динамически выделенной памятью. В этом случае при обращению к адресу в памяти происходит проверка на принадлежность его к какому-либо блоку и возможность доступа. Чтобы избежать проблем с динамическим выделением памяти и ускорить доступ к ней, StethoScope предоставляет возможность создания пула из некоторого числа буферов одинакового размера. Тогда, используя соответствующие функции доступа к этому пулу, можно осуществлять быстрый захват и освобождение его буферов.
Распределенный анализ.
При передаче данных на инструментальную сторону отладчик может производить их предварительный анализ - фильтрацию. Фильтрация представляет собой отбор данных в соответствии с некоторым заданным шаблоном (фильтром). Например, можно рассматривать события только некоторых определенных типов (переключение контекста, запуск задачи, и.т.д) или сравнивать полученные данные с некоторой маской значений. Фильтрация данных нужна, чтобы уменьшить вмешательство в работу целевой системы, то есть можно разбить отладку на несколько уровней: от минимального (исследование событий одного вида, например, переключение контекстов) до максимального (получение подробной информации о каждом событии в системе и данных о выполняемых задачах). В WindView представлены 3 уровня отладки:
протоколирование переключения контекстов
протоколирование состояний задач
протоколирование статусов системных объектов.
3) Профилирование системы
Под профилированием понимается один из способов мониторинга, позволяющий следить за выполнением некоторого множества задач (или всей системы) и предоставляющий пользователю информацию о том, как конкретная задача использует процессор (включая распределение времени в задаче).
Профилирование заключается в том, что с некоторой частотой производятся выборки данных об активных в этот промежуток времени задачах. При детальном профилировании собираются данные о каждой функции (количество ее вызовов, время выполнения). Приведем описание модуля ScopeProfile, входящего в StethoScope и представляющего собой типичный образец агента профилирования.
Сбор данных запускается либо специальной высокоприоритетной задачей, либо посредством ISR (Interrupt Service Routine). Существует два уровня профилирования: профилирование задачи способом "процедура за процедурой" (procedure-by-procedure) и профилирование системы способом "задача за задачей" (task-by-task). Основные параметры профилирования: частота выборки (sample rate) - частота, с которой производится сбор данных; частота анализа (analysis rate) - частота, с которой производится анализ имеющихся в буфере выборок. Анализирующая процедура представляет собой низкоприоритетную задачу, которая подсчитывает среднее из значений для задач и функций из всех выборок буфера и значений, полученных в ходе предыдущего анализа.
Цель профилирования задачи - выявить наиболее часто исполняемые блоки для последующей их оптимизации. Для этого служит способ "процедура за процедурой", позволяющий получать информацию о каждой вызываемой в процессе профилирования функции. Эта информация состоит из среднего времени, которое функция выполнялась, с учетом и без учета времени вызова из нее других функций. Также подсчитывается число ее вызовов. В результате анализа стека строится так называемое дерево выполнения (execution tree), показывающее маршрут вызова каждой функции.