Налагодження систем реального часу
К.А. Костюхін, НІІСІ РАН
1. Введення
1.1. Основні визначення
Предметом
цього огляду є налагодження систем реального часу.
Під
системою реального часу (СРВ) ми розуміємо систему, в якій коректність
функціонування залежить від дотримання часових обмежень.
Існуючі
СРВ є багатозадачними. Багатозадачність реалізується через
многопроцессность *) і багатопоточність.
Під
процесом розуміється власник ресурсів (наприклад, пам'ять, дані, дескриптори
відкритих файлів), які не розділяються з іншими процесами. У рамках одного
процесу виконуються один або декілька потоків. Вони спільно використовують
ресурси процесу.
Многопроцессность
в СРВ має суттєві недоліки, оскільки потребує підтримки часу
виконання для доступу до пам'яті, і, отже, при перемиканні контекстів
системі потрібно виконати додаткові дії.
Нить
- Це найбільш поширений підхід при проектуванні систем реального
часу, при якому СРВ являє собою один процес, в рамках якого
запущено декілька потоків.
Недоліком
багатопоточності є можливість модифікації чужих даних будь-якої
завданням (через відсутність захисту). У зв'язку з цим у СРВ представлені засоби
синхронізації, тобто кошти, що забезпечують завданням доступ до поділюваних
ресурсів. До таких засобів належать семафори (бінарні та лічильники), мьютекс,
черги повідомлень (див. [1], [3], [25]).
Структура
СРВ наведена на рис.1, де прикладної код - це сукупність призначених для користувача
потоків управління, ОСРВ - операційна система реального часу,
забезпечує планування, синхронізацію і взаємодію користувачів
потоків управління.
Рис. 1. Структура системи реального часу
Будемо
називати розподілену систему розподіленою системою реального часу
(РСРВ), якщо коректність її функціонування залежить також і від обмежень,
накладених на час обміну між компонентами системи.
1.2. Особливості налагодження в системах реального
часу
Налагодження
у СРВ спрямована на виявлення і виправлення помилок у прикладному коді. Вона
є одним з етапів крос-розробки, схему якої можна представити
наступним чином. Розробка програми ведеться як мінімум на двох машинах:
інструментальної та цільовий. На інструментальної платформі відбувається написання
вихідного тексту, компіляція та збирання. На цільової - завантажити програму, його
тестування і налагодження.
Зважаючи
того, що цільова платформа, як правило, має більш обмеженими
ресурсами, ніж інструментальна, налагодження розподілених систем реального
часу може бути двох видів.
Перший
з них - імітація архітектури цільової платформи, то є можливість налагодження
цільових програмних засобів без використання самої платформи. Подібна
імітація, як правило, не дає можливості провести детальне і повне
тестування ПЗ. Тому, такий тип налагодження застосовується тільки у випадку
відсутність цільової платформи.
Другий
спосіб - віддалена налагодження (крос-налагодження). Крос-налагодження дозволяє
використовувати ресурси інструментальної системи при вивченні поведінки деякого
процесу в цільовій системі.
Ефективність
віддаленої налагодження залежить від типу зв'язку інструментальної та цільової машин, а
також від підтримки засобів налагодження з боку цільової архітектури.
Співпадіння
вимогою до засобів налагодження є можливість спостерігати і аналізувати
весь процес виконання налагоджувати завдань, а також системи в цілому. У даній
роботі розглядаються два методи налагодження: активна налагодження та моніторинг.
Суть
активної налагодження полягає в тому, що відладчик має право зупиняти
виконання завдання або всієї системи, починати чи продовжувати виконання з
деякого адреси, відмінного від точки зупину, змінювати значення змінних і
регістрів, і.т.д. Недолік цього методу полягає в тому, що відладчик може
вносити серйозні збої в нормальну роботу системи у зв'язку з встановленими
тимчасовими обмеженнями. Цього можна уникнути, зупинивши деяку групу
завдань або всю систему цілком, про що буде докладніше сказано нижче. Перевага
методу полягає в можливості коректувати поведінку завдання в процесі її
виконання.
Під
моніторингом розуміється збір даних про завдання (значення регістрів, змінних,
и.т.д) або про систему в цілому (стадії виконання завдань, що відбуваються події,
и.т.д).
Здійснювати
збір даних допомагає псевдо-агент (набір інструкцій, що вбудовані в код задачі).
Зазвичай його додають на етапі проектування. Простий приклад псевдо-агента --
виклик assert, що дозволяє вести діагностику роботи завдання.
В
процесі моніторингу відладчик практично не втручається в роботу системи,
забезпечувати нормальне її функцірованіе, але разом з тим не має можливості
впливати на хід виконання налагоджувати програми.
1.3. Помилки в системах реального часу
Зазначені
вище методи налагодження дозволяють виявляти й усувати помилки наступного характеру:
Помилки
в програмному забезпеченні, що тягнуть неправильне виконання завдання
(безвідносно часу). Звичайні помилки, які виявляються засобами активної
налагодження. Ці кошти будуть розглянуті в розділі 2.
Помилки
в ОСРВ: помилки планування, синхронізації і связі.Для налагодження, в цьому випадку,
треба використовувати один із способів моніторингу. Докладно засоби моніторингу
описані в розділі 3.
Логіка
помилки, пов'язані з асинхронним. Приклад такого роду помилок і способи їх
усунення будуть приведені в розділі 4.
Помилки,
пов'язані з тим, що дані завдання були змінені іншим завданням. Локалізацію
помилок краще проводити, використовуючи моніторинг, а саме: здійснювати
періодичний контроль цілісності даних, тимчасово забороняти іншим завданням
доступ до деяких ділянках коду або даних.
2.
Засоби активної налагодження
2.1. Архітектура засобів активного налагодження
В
загальному випадку крос-відладчик складається з 2 основних модулів: менеджера на
інструментальної платформі і агента налагодження на цільової стороні. Менеджер служить
для забезпечення призначеного для користувача інтерфейсу, тобто для прийому команд, їх
обробки та посилки на цільову бік, а також для прийому, обробки та видачі
інформації від агента, який здійснює безпосередню роботу з
налагоджувати системою. Можливості агента налагодження залежать від особливостей
архітектури системи, а саме:
має
Чи система вбудовані засоби налагодження (в цьому випадку агенту достатньо
здійснювати виклик відповідних функцій і пересилати результати менеджеру);
які
вона надає можливості по створенню обробників (для контролю за
подіями, що відбуваються агенту може знадобитися власний обробник);
виклики
яких функцій дозволено робити агенту.
Крім
того, агент налагодження повинен підтримувати можливість прийому та передачі
інформації від псевдо-агентів, що вбудовані в код налагоджують програму. Агент
налагодження може складатися з декількох модулів, наприклад, один здійснює збір
даних, іншої виробляє фільтрацію, третій здійснює пересилання даних
менеджеру.
Загальна
структура активного крос-відладчика наведена на мал.2.
Рис. 2. Активний крос-відладчик
Розглянемо
протокол "менеджер-агент" на прикладі відладчика VxGDB (Wind River
Systems, цільова система - VxWorks). Цей протокол базується на RPC (Remote
Procedure Call). Запити менеджера можна класифікувати таким чином:
Запити
роботи з модулями Сюди відносяться запит на завантаження модуля, запит на отримання
інформації про завантажувальному фото і запит на отримання інформації про символ.
Запити
роботи із завданнями Це запити на запуск, зупинку і видалення завдання, на
приєднання і від'єднання від запущеної задачі, на встановлення та видалення
точки переривання, на продовження виконання зупиненої завдання.
ptrace-запити
Агент налагодження емулює функцію ptrace і передає їй відповідні запити на
читання і запис.
2.2. Налагодження дії
Існує
набір базових дій, що дозволяють користувачу здійснювати контроль за
виконанням налагоджувати завдання. Ці дії можна класифікувати таким
так:
попередні
дії відладчика;
переривання
виконання завдання;
отримання
інформації;
продовження/зміна
виконання завдання.
1)
Попередні дії відладчика
завантаження
модуля на цільової стороні;
запуск
потрібної задачі;
якщо
задача була запущена засобами системи, то приєднання до неї (у цьому випадку
виконання завдання зупиняється і стає можливим виробляти налагоджувальний
дії);
перемикання
між завданнями.
Усунення несправностей
також виконує і зворотні дії, тобто від'єднання від завдання,
припинення її виконання та вивантаження відповідного модуля.
2)
Переривання виконання завдання
Як
правило, виконання завдання може бути перерване в результаті того, що сталося
одне з наступних подій:
Досягнуто
точка переривання.
Точки
переривання бувають двох видів: програмні й апаратні. Установка програмної
точки переривання полягає в тому, що запам'ятовується інструкція, розташована по
тією адресою, де буде знаходитися точка переривання, потім за цією адресою
прописується так звана "break"-інструкція, після обробки
якої процесором генерується деякий виняток (trap exception).
Оброблювач цього виключення зберігає регістри завдання, змінює інструкцію точки
переривання на даний код і передає управління менеджеру. Недолік
програмних точок переривання в тому, що відповідний адреса повинна знаходитися
в тій області пам'яті, куди дозволений запис.
Апаратна
точка переривання не вимагає модифікації пам'яті, тому що її адресу зберігається в
спеціальному реєстрі (debug register, DR), що проглядається процесором
при виконанні чергової інструкції. Якщо відбуваються дії, закладені в
контрольний регістр (наприклад, виконання по заданому адресою або читання/запис
в область, що адресуються значенням DR), то процесор генерує відповідне
переривання, обробивши яке, відладчик отримує необхідну інформацію.
Усунення несправностей
надає користувачеві можливість установки точки переривання на початок
деякої рядка вихідного тексту, на точку входу певної функції або на
конкретну адресу. Крім цього, відладчик відрізняє точки переривання,
поставлені їм, а також (у багатозадачних системах) має можливість
встановлювати і обробляти точки переривання, специфічні для даного
безлічі завдань. Це означає, що якщо завдання не входить в таке налагоджувати
безліч, то точка переривання ігнорується.
Крім
роботи з точками переривання, що встановлюються на конкретну адресу, відладчик
працює з так званими переривань доступу (access breakpoints),
використовуються для визначення моменту доступу до деякої області пам'яті, і
переривань настання подій (event detection), які спрацьовують, коли
відбувається відповідна подія.
Використовується
режим покрокової налагодження.
Існує
багато варіантів ступеня деталізації виконання. Зокрема, зупинка після
виконання рядка вихідного тексту або зупинка після виконання кожної
асемблерні інструкції (із заходом в викликаються функції або з їх пропуском).
Усунення несправностей
може використовувати цей режим у службових цілях, наприклад, при встановленому
переривання виконання при зміні даних (watchpoint). У цьому випадку після
виконання черговий інструкції треба перевіряти значення того виразу, на
якому стоїть крапка переривання.
перехоплена
виняткова ситуація.
Якщо
в процесі виконання налагоджувати завдання виникла виняткова ситуація
(наприклад, ділення на 0), то відладчик повинен коректно її обробити і повідомити
користувачеві.
Отриманий
сигнал переривання від користувача.
Усунення несправностей
надає користувачеві можливість у будь-який момент зупинити виконання
програми (наприклад, ввівши відповідний символ).
При
отриманні сигналу зупинки відладчик може зупинити поточну налагоджувати
завдання, зупинити виконання певної групи завдань і зупинити всю систему.
Такий механізм дає можливість застосовувати засоби активної налагодження без
побоювання викликати нові помилки, пов'язані зі специфікою СРВ, оскільки система
або набір завдань, які можуть вплинути на налагоджувати, будуть зупинені, і
тимчасові співвідношення їх виконання порушені не будуть. Подібний підхід
реалізований в відладчик X-ray (Microtec Division, цільова система VRTX).
3)
Отримання інформації
Коли
завдання зупинилася, стає можливим здійснювати збір різних даних,
які можуть допомогти при локалізації логічних помилок в програмі.
Перегляд
вмісту стека.
Ця
команда дає можливість побачити, як завдання потрапила в поточне положення. Кожен
кадр стека містить дані, пов'язані з викликом певної функції, включаючи її
аргументи, локальні змінні і адреса точки виклику.
Перегляд
таблиці символів.
Використовуючи
відладчик, можна отримувати доступ до інформації про символи (імена змінних,
функцій і типів), визначених в задачі. Ця інформація складається з імені, типу
та адреси відповідної змінної або функції.
Перегляд
вихідних файлів.
Користувач
може вибірково дивитися вихідний текст програми, задаючи номери рядків, імена
функцій або деякий адресу.
Перегляд
даних.
Усунення несправностей
здатний одержувати і пересилати користувачеві значення будь-якої змінної або
функції, доступної налагоджувати завдання, а також вміст регістрів, пам'яті та
дизасемблювати код.
Крім
того, у користувача може виникнути необхідність здійснити в процесі
сеансу налагодження виклик деякої функції. Для підтримки цього існують
різні способи, наприклад, можна передати відповідний запит агенту
налагодження, і той запустить потрібну функцію або в контексті налагоджувати в
даний момент завдання, або в деякому спеціальному контексті. У GDB (GNU
debugger, Free Software Foundation) реалізований інший механізм, суть якого
полягає в тому, що всі попередні дії (установка точки
виконання, і.т.д.) виробляються на інструментальній стороні, а агенту
передається запит на виконання з поточного адреси.
4)
Продовження/зміна виконання
Особливістю
активної налагодження є можливість зміни виконання завдання.
Зміна
даних.
Усунення несправностей
має можливість змінювати значення змінних, вміст регістрів і пам'яті.
Це дозволяє коригувати виконання завдання, перевіряючи припущення про
помилки в її коді.
Продовження
виконання завдання з будь-якою адресою.
Користувач
може вимагати продовжити виконання завдання з іншої адреси (наприклад,
обходячи критичний ділянка коду).
Продовження
виконання завдання до деякого адреси.
В
цьому випадку ставиться тимчасова точка переривання на потрібну адресу, і завдання
виконується, поки ця адреса не буде досягнуто. Як і у випадку зі звичайною
точкою переривання, відладчик забезпечує встановлення тимчасової точки переривання
на початок рядка вихідного тексту, на конкретну адресу або на точку входу
деякої функції. Однак, крім цього відладчик може ставити тимчасову крапку
переривання на адресу повернення поточної функції, реалізуючи виконання завдання аж
до завершення цієї функції.
Механізм
встановлення тимчасової точки переривання використовується і в режимі покрокової налагодження.
Тоді точка переривання ставиться на наступну виконувану інструкцію або (у
разі налагодження без заходу в викликаються функції) на інструкцію, наступну за
викликом функції.
Повернення
з функції.
Може
виникнути ситуація, коли користувачеві знадобиться завершити виконання функції
з певним що повертається значенням. У цьому випадку відладчик виконує
наступні дії:
Приведення
заданого користувачем значення до типу значення, що повертається цієї функції.
Відновлення
збережених регістрів.
Установка
значення, що повертається в потрібну область пам'яті/регістр.
Установка
покажчика стека на попередній кадр.
Установка
точки виконання програми на адресу повернення заданої функції.
Знищення
поточного кадру стека.
Описуючи
налагоджувальний дейнаслідком, варто згадати про інструментальну системі Ескорт ([27]),
створеної в Науково-дослідному інституті системних досліджень РАН як
засіб підвищення продуктивності праці професійних програмістів.
Основу Ескорт становить інтегрована система редагування - компіляції --
виконання.
Програми
в ескорт мають нетекстові подання. Більш точно, всі програмні об'єкти
представлені як об'єкти бази даних. Засобами БД Ескорт реалізовано
зберігання попередніх станів об'єктів (і, зокрема, значень змінних),
відкатку, "відкатку відкочування" і т.п., що дозволяє дати в руки
програмісту потужні засоби контрольованого виконання (покрокове, з контролем
значень змінних, зворотне і т.д.). Правда, на сьогоднішній день, для
сучасних систем реального часу, кошти, які пропонуються в рамках ескорту,
представляються занадто важкими (хоча й дуже перспективними).
2.3. Інтерфейс користувача
Крім
отримання необхідної інформації відладчик повинен надати її в зручному для
користувача вигляді. Для цього служать інтерфейсні команди і функції.
Інтерфейс
відладчика складається з:
графічного
інтерфейсу;
режиму
комадной рядка;
команд
представлення даних.
1)
Графічний інтерфейс
Основне
вимога, що пред'являється до графічного інтерфейсу активного відладчика --
одночасна візуалізація інформації про налагоджувати задачі (наприклад, вікно
вихідного тексту, діалогове вікно, вікно відображення даних та повідомлень). При
налагодження групи завдань, необхідно відображати повну інформацію про кожну з них,
як це реалізовано в X-ray.
2)
Режим командного рядка
В
режимі командного рядка відладчик повинен надавати користувачеві можливість
редагувати вводяться команди, а також підтримувати зберігання раніше введених
команд у деякому буфері з метою їх подальшого виклику і модифікації.
3)
Команди подання даних
Наведемо
деякі способи представлення та зберігання даних, реалізація яких у
значній мірі спрощує роботу користувача:
Історія
значень.
Зберігання
раніше відображених значень дозволяє стежити за зміною інспектіруемое
вирази. Значення можуть зберігатися в деякому буфері або файлі.
Внутрішній
мова відладчика.
Внутрішній
мова - засіб, що дає можливість користувачу визначати власні
функції. Крім цього відладчик може мати вбудованим інтерпретатором
якого-небудь відомого мови сценаріїв. Наприклад, VxGDB володіє вбудованим
TCL-інтерпретатором, що дозволяє не тільки визначати нові функції обробки
даних, а й (за підтримки з боку цільової) емулювати ряд функцій VxWorks.
Підтримка
різних форматів представлення даних.
Вже
згадувані кошти налагодження (VxGDB, X-Ray) надають можливість виводу
цікавить значення в будь-якому числовому або символьному форматі. Крім того, в
них є підтримка складних елементів мови, таких як масиви або структури.
Підтримка
декількох мов.
Якщо
програма зібрана з модулів, написаних на різних мовах програмування, то
для її повноцінної відладки необхідна підтримка всіх цих мов. Крім того,
VxGDB підтримує синтаксис основних мов програмування (C, fortran) для
свого внутрішнього мови, забезпечуючи автоматичну його зміну при виконанні
функцію, реалізовану на мові, відмінному від поточного.
Регулярний
відображення даних.
При
налагодження може знадобитися перегляд деяких даних (або виконання команд)
при кожній зупинці завдання.
GDB
в даному випадку надає такі можливості:
Команда
display. Після зупинки виконання завдання (але не у випадку, коли вона
завершилася) проводиться відображення даних, заданих в якості аргументів
цієї команди.
Команда
commands прив'язує до точки переривання, номер якої заданий як
аргументу, набір дій, які потрібно реалізувати відладчику при досягненні
цієї точки переривання.
2.4. Інтеграція із засобами розробки ПЗ
Зазвичай,
програмний продукт проходить стадії розробки, представлені на рис.3.
Рис. 3. Стадії розробки ПЗ
В
[24] описаний спосіб, що дозволяє зменшити загальний час розробки програмного
продукту за рахунок об'єднання засобів тестування і налагодження. Таку можливість
надає відладчик Pilot (Kvatro Telecom). Подібне поєднання має наступні
перевагами:
відразу
виявляються помилки в тесті;
є
можливість генерувати тести в процесі налагодження;
результати
тесту відразу обробляються і у випадку помилки передаються відладчику, який
інтерактивно відтворює цей тест.
Засоби
підтримки налагодження можуть закладатися на стадії написання початкового тексту та
компіляції. Під час написання початкового тексту в програмний продукт може
закладатися псевдо-агент - набір функцій, що здійснюють деякі налагоджувальний
дії.
Для
налагодження з використанням вихідних текстів програми, необхідно при компіляції
генерувати додаткову інформацію, що складається з описів символів
програми (змінні, функції, типи) і псевдо-символів, що дозволяють відладчику
визначати адреси рядків вихідного тексту, адреси секцій, і.т.д.
3.
Засоби моніторингу
3.1. Архітектура засобів моніторингу
Архітектура
засобів моніторингу в загальному випадку збігається з архітектурою засобів активної
налагодження, з тією лише різницею, що агенту налагодження заборонено зупиняти
налагоджувати завдання і модифікувати її дані. Взагалі, основна вимога до
засобів моніторингу - збір даних з мінімальним втручанням в роботу
цільової системи. Для цього агенту налагодження потрібно якомога рідше звертатися до
менеджеру, тобто зберігати отримані дані в деякому буфері і пересилати їх
в міру заповнення буфера. Крім того, при пересиланні даних можна проводити
їх фільтрацію або сортування у відповідність з деяким критерієм значимості.
При
моніторингу агенту налагодження не потрібно підтримувати прямого зв'язку з
псевдо-агентами, так як псевдо-агенти можуть надсилати зібрані дані в буфер,
де вони будуть накопичуватися разом з іншими даними.
Рис. 4. Архітектура відладчика, що здійснює
моніторинг
3.2. Налагодження дії
налагодження
дії при моніторингу можна розділити на наступні категорії:
збір
даних;
аналіз
даних;
профілювання
системи;
"посмертний"
аналіз.
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), що показує
маршрут виклику кожної функції.
Спосіб
"завдання за завданням" служить для збору інформації про активність системи
в цілому, а саме, яке процесорний час використовує кожна завдання.
4)
"Посмертний" (post-mortem) аналіз
Подібний
аналіз виконується в тому випадку, якщо в роботі системи відбувся збій. Тоді
користувача цікавлять не всі події, а тільки ті, які відбулися за
деякий час до "обвалу" системи. У цьому випадку, щоб вплив
відладчика на систему було зведено до мінімуму, всі дані зберігаються в
деякому буфері і оновлюються в міру його заповнення, але не пересилаються на
інструментальну сторону. Адреса для буфера треба вибирати так, щоб при
перезавантаження системи його вміст не знищувалося. У VxWorks це можна
реалізувати наступним чином: треба змінити функцію sysMemTop (), що визначає
верхній адреса локальної пам'яті, так, щоб вона повертала значення, менше
дійсного адреси. Тоді в утворився адресному просторі,
недоступному системі, можна розташувати буфер даних. В результаті після
перезавантаження в розпорядження відладчика надходять дані про останні події,
що відбулися в системі і, можливо, що призвели до її збій.
3.3. Інтерфейс користувача
При
аналізі даних або профілювання важливу роль грає представлення отриманої
інформації. Як і у випадку активної налагодження користувальницький інтерфейс ділиться
на три складових: графічний інтерфейс, інтерфейс командного рядка і команди
представлення даних.
Графічне
подання даних - найбільш важлива частина для користувача інтерфейсу при
моніторингу. Оскільки, як правило, аналізується взаємодія завдань у
системі, то потрібна візуалізація всіх подій і завдань системи. У WindView для
цього є спеціальне вікно View Graph. По горизонталі відкладається час
(одиничний інтервал часу може мінятися), по вертикалі наведений список усіх
завдань у системі і рівні переривань. У такій системі координат легко побачити,
яке завдання в який момент часу в якому стані перебувала. Особливими
значками відзначаються події, що відбуваються, подробиці про яких (також як і про
завданнях) можна побачити в іншому вікні.
При
моніторингу поточного стану системи зручно користуватися графічним
інтерфейсом, але при аналізі збережених раніше даних, а також при
"посмертної" налагодження, можна використовувати режим командного рядка.
Вимоги до нього пред'являються аналогічні тим, що були у засобів активної
налагодження.
Крім
описаних у попередньому розділі команд подання даних у активних відладчиком
засоби моніторингу можуть мати у своєму розпорядженні також такими командами:
виконання
деякої послідовності дій при сталося подію, що надійшов
сигналі або настання певного моменту часу;
визначення
користувачем власних подій (eventpoints в WindView) і сигналів
(комбінації відомих сигналів "derived signals" в StethoScope).
3.4. Інтеграція із засобами розробки ПЗ
При
моніторингу особливе?? Німанн приділяється роботі псевдоагентов, які
закладаються в код програми на етапі компіляції. Для їх успішної роботи з
збору необхідної інформації потрібна наявність на цільовий машині ряду функцій,
викликаються псевдо-агентами. Ці функції можуть бути зібрані в одну бібліотеку,
так звану бібліотеку доступу (access library).
В
[20] описується засіб роботи з псевдо-агентами - "Alamo monitor".
На Рис.5 наведено його архітектура.
Рис. 5. Alamo monitor
Координатор
моніторингу посилає запити псевдо-агентові і проводить фільтрацію отриманої
інформації.
Рис. 6. Отримання інформації від псевдо-агента
В
залежно від можливостей, що надаються бібліотекою доступу, змінюється і
роль псевдо-агентів. Можлива ситуація, коли на цільової стороні присутня
тільки агент доставки даних з буфера, а всі дані поставляються
псевдо-агентами. Такий підхід зменшує вплив відладчика на систему, так
як все налагоджувальний дії закладені при компіляції, і агент налагодження тільки
передає дані менеджеру в міру заповнення буфера, тобто не впливає на хід
виконання налагоджувати завдань.
Є
й інше застосування псевдо-агентів. За допомогою вбудовування в код програми
деякого некоректно працюючого блоку, можна моделювати критичні
ситуації та аналізувати поведінку завдання або всієї системи в таких ситуаціях.
4.
Особливості налагодження многоплатформних розподілених систем
4.1. Особливості архітектури
Якщо
раніше система реального часу розглядалася нами як один процес (з точки
зору ресурсів), то розподілені СРВ представляють уже набір
взаємодіючих процесів.
Специфіка
полягає в тому, що налагоджувати додаток може бути розподілено на
декількох платформах з різними процесорами, тому ефективність відладчика
залежить від:
наявності
на кожному компоненті системи агента налагодження;
здібності
менеджера працювати з усіма процесорами системи;
можливості
агентів налагодження здійснювати зв'язок між собою і з менеджером.
Крім
того, якщо система складається з великої кількості компонент, використання
дворівневої архітектури "менеджер-агент" стає неефективним,
оскільки менеджер не зможе обробити в належний час інформацію від
агентів. У цьому випадку доцільно використовувати багаторівневу структуру, в
якої компоненти, об'єднані за своїми функціональними можливостями,
представляють деякі підсистеми, якими керують відповідні
менеджери, які є агентами на наступному рівні запропонованої ієрархії.
При
включення в систему нової платформи необхідно, щоб менеджер мав можливість
здійснювати зв'язок з агентом. Для цього до набору вихідних текстів менеджера
додається файл, що містить функції взаємодії з агентом. Тут можливі
наступні варіанти:
Файл
опису платформи вимагає компіляції і збірки разом з іншими вихідними
текстами.
Істотний
недолік такого
