Структура операционной системы THE
Уровень 1 управлял памятью. Он выделял процессам пространство в оперативной памяти и на магнитном барабане объемом 512 К слов для тех частей процессов (страниц), которые не помещались в оперативной памяти. Процессы более высоких уровней не заботились о том, находятся ли они в данный момент в памяти или на барабане. Программное обеспечение уровня 1 обеспечивало попадание страниц в оперативную память по мере необходимости.
Уровень 2 управлял связью между консолью оператора и процессами. Таким образом, все процессы выше этого уровня имели свою собственную консоль оператора. Уровень 3 управлял устройствами ввода/вывода и буферизовал потоки информации к ним и от них. Любой процесс выше уровня 3 вместо того, чтобы работать с конкретными устройствами, с их разнообразными особенностями, мог обращаться к абстрактным устройствам ввода/вывода, обладающим удобными для пользователя характеристиками. На уровне 4 работали пользовательские программы, которым не надо было заботиться ни о процессах, ни о памяти, ни о консоли, ни об управлении устройствами ввода/вывода. Процесс системного оператора размещался на уровне 5.
Дальнейшее обобщение многоуровневой концепции было сделано в операционной системе MULTICS . В ней уровни представляли собой серию концентрических колец, где внутренние кольца являлись более привилегированными, чем внешние. Когда процедура внешнего кольца хотела вызвать процедуру кольца, лежащего внутри, она должна была выполнить эквивалент системного вызова, то есть команду TRAP , параметры которой тщательно проверяются перед тем, как выполняется вызов. Хотя операционная система в MULTICS являлась частью адресного пространства каждого пользовательского процесса, аппаратура обеспечивала защиту данных на уровне сегментов памяти, разрешая или запрещая доступ к индивидуальным процедурам (в действительности к сегментам памяти) для записи, чтения или выполнения.
|
|
|
Стоит отметить, что в системе THE многоуровневая схема представляла собой исключительно конструкционное решение и все части системы были, в конечном счете, связаны в один объектный файл, а в MULTICS механизм разделения колец действовал во время исполнения на аппаратном уровне.
Преимущество подхода MULTICS заключается в том, что его можно расширить и на структуру пользовательских подсистем. Например, профессор может написать программу для тестирования и оценки студенческих программ и запустить ее в кольце п, в то время как студенческие программы будут работать в кольце п + 1, так что они не смогут изменить свои оценки.
Модуль 2. ТРЕБОВАНИЯ К ОПЕРАЦИОННЫМ СИСТЕМАМ РЕАЛЬНОГО ВРЕМЕНИ
|
|
|
ТЕМА 1. МУЛЬТИПРОГРАММНОСТЬ И МУЛЬТИЗАДАЧНОСТЬ
Как известно, система реального времени (СРВ) должна давать отклик на любые непредсказуемые внешние воздействия в течение предсказуемого интервала времени. Для этого должны выполняться следующие требования.
Ограничение времени отклика. После наступления события реакция на него гарантированно должна последовать до предустановленного крайнего срока. Отсутствие такого ограничения рассматривается как серьезный недостаток программного обеспечения.
Одновременность обработки. Даже если наступает более одного события одновременно, все временные ограничения для всех событий должны быть выдержаны. Это означает, что системе реального времени должен быть присущ параллелизм, что достигается использованием нескольких процессоров и/или многозадачного подхода.
Примерами систем реального времени являются системы управления атомными электростанциями или какими-нибудь технологическими процессами, системы медицинского мониторинга, системы управления вооружением, системы космической навигации, системы разведки, системы управления лабораторными экспериментами, системы управления автомобильными двигателями, робототехника, телеметрические системы управления, системы антиблокировки тормозов, системы сигнализации — список в принципе бесконечен.
|
|
|
Иногда можно услышать из разговоров специалистов, что различают системы «мягкого» и «жесткого» реального времени. Различие между жесткой и мягкой СРВ зависит от требований к системе — система считается жесткой, если «нарушение временных ограничений недопустимо», и мягкой, если «нарушение временных ограничений нежелательно». В недалеком прошлом велось множество дискуссий о точном смысле терминов «жесткая» и «мягкая» СРВ. Можно даже показать, что мягкая СРВ не является СРВ вовсе, ибо основное требование о соблюдении временных ограничений не выполнено. В действительности термин СРВ часто неправомерно применяют по отношению к быстрым системам.
Часто путают понятия СРВ и ОСРВ (операционная система реального времени) а также неправильно используют атрибуты «мягкая» и «жесткая», когда говорят что та или иная ОСРВ мягкая или жесткая. Нет мягких или жестких операционных систем реального времени. ОСРВ может только служить основой для построения мягкой или жесткой СРВ. Сама по себе ОСРВ не препятствует тому, что ваша СРВ будет мягкой. Например, пусть вы решили создать СРВ, которая должна работать через Ethernet по протоколу TCP/IP. Такая система не может быть жесткой СРВ, поскольку сама сеть Ethernet в принципе непредсказуема вследствие использования случайного метода доступа к среде передачи данных, в отличие, например, от сети IBM Token Ringили ARC Net , в которых используются детерминированные методы доступа.
|
|
|
Итак, перечислим основные требования к ОСРВ.
Мультипрограммность и мультизадачность
Требование 1.Операционная система должна быть мультипрограммной и мультизадачной (многопоточной — multi - threaded ), а также активно использовать прерывания для диспетчеризации. Как указывалось выше, ОСРВ должна быть предсказуемой. Это означает не то, что ОСРВ должна быть быстрой, а то, что максимальное время выполнения того или иного действия должно быть известно заранее и соответствовать требованиям приложения. Так, например, система Windows 3.11 даже на Pentium IV с частотой более 3000 МГц не может функционировать в качестве ОСРВ, ибо одно приложение может практически монопольно захватить центральный процессор и заблокировать систему для остальных вычислений.
В соответствии с первым требованием операционная система должна быть многопоточной на принципе абсолютного приоритета (прерываемой). То есть планировщик должен иметь возможность прервать любой поток выполнения и предоставить ресурс тому потоку, которому он более необходим. Операционная система (и аппаратура) должна также обеспечивать прерывания на уровне обработки прерываний.
ТЕМА 2. ПРИОРИТЕТЫ ЗАДАЧ
Требование 2.Должно существовать понятие приоритета потока (задачи). Проблема в том, чтобы определить, какой задаче ресурс требуется более всего. В идеальной ситуации ОСРВ отдает ресурс потоку или драйверу с ближайшим крайним сроком, что называется управлением временным ограничением ( Deadline DrivenOS ). Чтобы реализовать это временное ограничение, операционная система должна знать, сколько времени требуется каждому из выполняющихся потоков для завершения. Операционных систем, построенных по этому принципу, практически нет, так как он слишком сложен для реализации. Поэтому разработчики операционных систем принимают иную точку зрения: вводится понятие уровня приоритета для задач и временные ограничения сводятся к приоритетам. Так как умозрительные решения чреваты ошибками, показатели СРВ при этом снижаются. Чтобы более эффективно осуществить указанное преобразование ограничений, проектировщик может воспользоваться теорией расписаний или имитационным моделированием, хотя и это может оказаться бесполезным. Тем не менее, так как на сегодняшний день не имеется иного решения, без понятия приоритета потока не обойтись.
ТЕМА 3. НАСЛЕДОВАНИЕ ПРИОРИТЕТОВ
Требование 3.Должна существовать система наследования приоритетов. На самом деле именно этот механизм синхронизации и тот факт, что различные потоки выполнения используют одно и то же пространство памяти, отличают их от процессов. Как мы уже знаем, процессы не разделяют одно и то же пространство памяти. Так, например, старые версии UNIX не являются многопоточными. «Старая» UNIX — многозадачная ОС, где задачами являются процессы (а не потоки), которые сообщаются через каналы связи ( pipes ) и разделяемую память. Оба этих механизма используют файловую систему, а ее поведение непредсказуемо.
Комбинация приоритетов потоков и разделение ресурсов между ними приводит к другому явлению — классической проблеме инверсии приоритетов. Это можно проиллюстрировать на примере, где есть как минимум три потока. Когда поток низшего приоритета захватил ресурс, разделяемый с потоком высшего приоритета, и начал выполняться поток среднего приоритета, выполнение потока высшего приоритета будет приостановлено, пока не освободится ресурс и не отработает поток среднего приоритета. В этой ситуации время, необходимое для завершения потока высшего приоритета, зависит от нижних уровней приоритетов — это и есть инверсия приоритетов. Ясно, что в такой ситуации трудно выдержать ограничение на время исполнения.
Чтобы устранить такие инверсии, ОСРВ должна допускать наследование приоритета, то есть повышение уровня приоритета потока до уровня потока, который его вызывает. Наследование означает, что блокирующий ресурс поток наследует приоритет потока, который он блокирует (разумеется, это справедливо лишь в том случае, если блокируемый поток имеет более высокий приоритет).
Иногда можно услышать утверждение, что в грамотно спроектированной системе такая проблема не возникает. В случае сложных систем с этим нельзя согласиться. Единственный способ решения этой проблемы состоит в увеличении приоритета потока «вручную» прежде, чем ресурс окажется заблокированным. Разумеется, это возможно в случае, когда два потока разных приоритетов претендуют на один ресурс В общем случае решения не существует.
ТЕМА 4. СИНХРОНИЗАЦИЯ ПРОЦЕССОВ И ЗАДАЧ
Требование 4.Операционная система должна обеспечивать мощные, надежные и удобные механизмы синхронизации задач. Так как задачи разделяют данные (ресурсы) и должны сообщаться друг с другом, представляется логичным существование механизмов блокирования и коммуникации. То есть необходимы механизмы, гарантированно предоставляющие возможность оперативно обменяться сообщениями и синхросигналами между параллельно выполняющимися задачами и процессами. Эти системные механизмы должны быть всегда доступны процессам требующим реального времени. Следовательно, системные ресурсы для их функционирования должны быть распределены заранее.
ТЕМА 5. ПРЕДСКАЗУЕМОСТЬ
Требование 5.Поведение операционной системы должно быть известно и достаточно точно прогнозируемо. Времена выполнения системных вызовов и временные характеристики поведения системы в различных обстоятельствах должны быть известны разработчику. Поэтому создатель ОСРВ должен приводить следующие характеристики:
латентную задержку прерывания, то есть время от момента прерывания до момента запуска задачи: она должна быть предсказуема и согласована с требованиями приложения (эта величина зависит от числа одновременно «висящих» прерываний);
максимальное время выполнения каждого системного вызова (оно должно быть предсказуемо и не должно зависеть от числа объектов в системе);
максимальное время маскирования прерываний драйверами и супервизорными модулями операционной системы.
ТЕМА 6. ИНТЕРФЕЙСЫ ОПЕРАЦИОННЫХ СИСТЕМ
Напомним, что операционная система всегда выступает как интерфейс между аппаратурой компьютера и пользователем с его задачами. Под интерфейсами операционных систем здесь и далее следует понимать специальные интерфейсы системного и прикладного программирования ( API ), предназначенные для выполнения перечисленных ниже задач.
Управление процессами, которое включает в себя следующий набор основных функций:
• запуск, приостановка и снятие задачи с выполнения;
• задание или изменение приоритета задачи;
• взаимодействие задач между собой (механизмы сигналов, семафорные примитивы, очереди, конвейеры, почтовые ящики);
• вызов удаленных процедур (Remote Procedure Call, RPC).
Управление памятью:
• запрос на выделение блока памяти;
• освобождение памяти;
• изменение параметров блока памяти (например, память может быть заблокирована процессом либо предоставлена в общий доступ);
• отображение файлов на память (имеется не во всех системах).
Управление вводом-выводом:
• запрос на управление виртуальными устройствами (напомним, что управление вводом-выводом является привилегированной функцией самой операционной системы, и никакая из пользовательских задач не должна иметь возможности непосредственно управлять устройствами);
• файловые операции (запросы к системе управления файлами на создание, изменение и удаление данных, организованных в файлы).
Здесь мы перечислили основные наборы функций, которые выполняются операционной системой по соответствующим запросам от задач. Что касается интерфейса пользователя с операционной системой, то он реализуется с помощью специальных программных модулей, которые принимают его команды на соответствующем языке (возможно, с использованием графического интерфейса) и транслируют их в обычные вызовы в соответствии с основным интерфейсом системы. Обычно эти модули называют интерпретатором команд. Так, например, функции такого интерпретатора в MS DOSвыполняет модуль C О MMAND . COM . Получив от пользователя команду, такой модуль после лексического и синтаксического анализа либо сам выполняет действие, либо, что случается чаще, обращается к другим модулям операционной системы, используя механизм API . Надо заметить, что в последние годы большую популярность получили графические интерфейсы ( Graphical User Interface , GUI ), в которых задействованы соответствующие манипуляторы типа мышь или трекбол ( track - ball ) . Указание курсором на объект и щелчок или двойной щелчок на соответствующей кнопке мыши приводит к каким-либо действиям — запуску программы, ассоциированной с объектом, выбору и/или активизации меню и т. д. Можно сказать, что такая интерфейсная подсистема транслирует «команды» пользователя в обращения к операционной системе.
Поясним также, что управление GUI(гуй) является частным случаем задачи управления вводом-выводом и не относится к функциям ядра операционной системы, хотя в ряде случаев разработчики операционной системы относят функции GUI к основному системному интерфейсу API .
Следует отметить, что имеются два основных подхода к управлению задачами. Так, в одних системах порождаемая задача наследует все ресурсы задачи-родителя, тогда как в других системах существуют равноправные отношения, и при порождении нового процесса ресурсы для него запрашиваются у операционной системы.
Обращения к операционной системе в соответствии с имеющимся интерфейсом API могут осуществляться как посредством вызова подпрограммы с передачей ей необходимых параметров, так и через механизм программных прерываний. Выбор метода реализации вызовов функций API должен определяться архитектурой платформы.
Так, например, в операционной системе MS DOS , которая разрабатывалась для однозадачного режима (поскольку процессор i 80 x 86 не поддерживал мультипрограммирование), использовался механизм программных прерываний. При этом основной набор функций API был доступен через точку входа обработчика int 21 h . В более сложных системах имеется не одна точка входа, а множество — по количеству функций API . Так, в большинстве операционных систем используется метод вызова подпрограмм. В этом случае вызов сначала передается в модуль API , например в библиотеку времени выполнения ( Run Time Library , RTL ) , который перенаправляет его соответствующим обработчикам программных прерываний, входящим в состав операционной системы. Использование механизма прерываний вызвано, главным образом, тем, что при этом процессор переводится в режим супервизора.
ТЕМА 7. СРЕДСТВА АКТИВНОЙ ОТЛАДКИ ОПЕРАЦИОННЫХ СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ
Архитектура средств активной отладки
В общем случае кросс-отладчик состоит из 2 основных модулей: менеджера на инструментальной платформе и агента отладки на целевой стороне. Менеджер служит для обеспечения пользовательского интерфейса, то есть для приема команд, их обработки и посылки на целевую сторону, а также для приема, обработки и выдачи информации от агента, который осуществляет непосредственную работу с отлаживаемой системой. Возможности агента отладки зависят от особенностей архитектуры системы, а именно:
● имеет ли система встроенные средства отладки (в этом случае агенту достаточно осуществлять вызов соответствующих функций и пересылать результаты менеджеру);
● какие она предоставляет возможности по созданию обработчиков (для контроля за происходящими событиями агенту может потребоваться собственный обработчик);
● вызовы каких функций дозволено делать агенту.
Кроме того, агент отладки должен поддерживать возможность приема и передачи информации от псевдоагентов, встроенных в код отлаживаемых программ. Агент отладки может состоять из нескольких модулей, например, один осуществляет сбор данных, другой производит фильтрацию, третий осуществляет пересылку данных менеджеру.
Общая структура активного кросс-отладчика приведена на рис. 2.
Рис. 2. Активный кросс-отладчик
Рассмотрим протокол «менеджер-агент» на примере отладчика VxGDB (Wind River Systems, целевая система — VxWorks). Этот протокол базируется на RPC (Remote Procedure Call). Запросы менеджера можно классифицировать следующим образом:
1. Запросы работы с модулями
Сюда относятся запрос на загрузку модуля, запрос на получении информации о загрузочном файле и запрос на получение информации о символе.
2. Запросы работы с задачами
Это запросы на запуск, остановку и удаление задачи, на присоединение и отсоединение от запущенной задачи, на установку и удаление точки прерывания, на продолжение выполнения остановленной задачи.
3. ptrace-запросы
Агент отладки эмулирует функцию ptrace и передает ей соответствующие запросы на чтение и запись.
Отладочные действия
Существует набор базовых действий, позволяющих пользователю осуществлять контроль за выполнением отлаживаемой задачи. Эти действия можно классифицировать следующим образом:
● предварительные действия отладчика;
● прерывание выполнения задачи;
● получение информации;
● продолжение/изменение выполнения задачи.
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) Продолжение/изменение выполнения
Особенностью активной отладки является возможность изменения выполнения задачи.
● Изменение данных.
Отладчик имеет возможность изменять значения переменных, содержимое регистров и памяти. Это позволяет корректировать выполнение задачи, проверяя предположения об ошибках в ее коде.
● Продолжение выполнения задачи с любого адреса.
Пользователь может потребовать продолжить выполнение задачи с другого адреса (например, обходя критический участок кода).
● Продолжение выполнения задачи до некоторого адреса.
В этом случае ставится временная точка прерывания на нужный адрес, и задача выполняется, пока этот адрес не будет достигнут. Как и в случае с обычной точкой прерывания, отладчик обеспечивает установку временной точки прерывания на начало строки исходного текста, на конкретный адрес или на точку входа некоторой функции. Однако, помимо этого отладчик может ставить временную точку прерывания на адрес возврата текущей функции, реализуя выполнение задачи вплоть до завершения этой функции.
Механизм установки временной точки прерывания используется и в режиме пошаговой отладки. Тогда точка прерывания ставится на следующую исполняемую инструкцию или (в случае отладки без захода в вызываемые функции) на инструкцию, следующую за вызовом функции.
● Возврат из функции.
Может возникнуть ситуация, когда пользователю понадобится завершить выполнение функции с определенным возвращаемым значением. В этом случае отладчик выполняет следующие действия:
a. Приведение заданного пользователем значения к типу возвращаемого значения этой функции.
b. Восстановление сохраненных регистров.
c. Установка возвращаемого значения в требуемую область памяти/регистр.
d. Установка указателя стека на предыдущий кадр.
e. Установка точки выполнения программы на адрес возврата заданной функции.
f. Уничтожение текущего кадра стека.
Описывая отладочные действия, стоит упомянуть об инструментальной системе ЭСКОРТ, созданной в Научно-исследовательском институте системных исследований РАН как средство повышения производительности труда профессиональных программистов. Основу ЭСКОРТа составляет интегрированная система редактирования — компиляции — выполнения.
Программы в ЭСКОРТе имеют нетекстовое представление. Более точно, все программные объекты представлены как объекты базы данных. Средствами БД ЭСКОРТа реализовано хранение предыдущих состояний объектов (и, в частности, значений переменных), откатка, «откатка откатки» и т. п., что позволяет дать в руки программисту мощные средства контролируемого выполнения (пошаговое, с контролем значений переменных, обратное и т. д.). Правда, на сегодняшний день, для современных систем реального времени, средства, предлагаемые в рамках ЭСКОРТа, представляются слишком тяжеловесными (хотя и весьма перспективными).
Пользовательский интерфейс
Помимо получения необходимой информации отладчик должен предоставить ее в удобном для пользователя виде. Для этого служат интерфейсные команды и функции.
Интерфейс отладчика состоит из:
● графического интерфейса;
● режима командной строки;
● команд представления данных.
1) Графический интерфейс
Основное требование, предъявляемое к графическому интерфейсу активного отладчика — одновременная визуализация информации об отлаживаемой задаче (например, окно исходного текста, диалоговое окно, окно отображения данных и сообщений). При отладке группы задач, необходимо отображать полную информацию о каждой из них, как это реализовано в X-ray.
2) Режим командной строки
В режиме командной строки отладчик должен предоставлять пользователю возможность редактировать вводимые команды, а также поддерживать хранение ранее введенных команд в некотором буфере с целью их последующего вызова и модификации.
3) Команды представления данных
Приведем некоторые способы представления и хранения данных, реализация которых в значительной степени упрощает работу пользователя:
● История значений.
Хранение ранее отображенных значений позволяет следить за изменением инспектируемого выражения. Значения могут храниться в некотором буфере или файле.
● Внутренний язык отладчика.
Внутренний язык — средство, дающее возможность пользователю определять собственные функции. Кроме этого отладчик может обладать встроенным интерпретатором какого-нибудь известного языка сценариев. Например, VxGDB обладает встроенным TCL-интерпретатором, позволяющим не только определять новые функции обработки данных, но и (при поддержке с целевой стороны) эмулировать ряд функций VxWorks.
● Поддержка разных форматов представления данных.
Уже упоминавшиеся средства отладки (VxGDB, X-Ray) предоставляют возможность вывода интересующего значения в любом числовом или символьном формате. Кроме того, в них имеется поддержка сложных элементов языка, таких как массивы или структуры.
● Поддержка нескольких языков.
Если программа собрана из модулей, написанных на разных языках программирования, то для ее полноценной отладки необходима поддержка всех этих языков. Кроме того, VxGDB поддерживает синтаксис основных языков программирования (C, fortran) для своего внутреннего языка, обеспечивая автоматическую его смену при выполнении функции, реализованной на языке, отличном от текущего.
● Регулярное отображение данных.
При отладке может потребоваться просмотр некоторых данных (или выполнение команд) при каждой остановке задачи.
GDB в данном случае предоставляет следующие возможности:
a. Команда display. После остановки выполнения задачи (но не в случае, когда она завершилась) производится отображение данных, заданных в качестве аргументов этой команды.
b. Команда commands привязывает к точке прерывания, номер которой задан в качестве аргумента, набор действий, которые нужно реализовать отладчику при достижении этой точки прерывания.
Интеграция со средствами разработки ПО
Обычно, программный продукт проходит стадии разработки, представленные на рис. 3.
Рис. 3. Стадии разработки ПО
В «Integrated testing and debugging of concurrent software systems » описан способ, позволяющий уменьшить общее время разработки программного продукта за счет объединения средств тестирования и отладки. Такую возможность предоставляет отладчик Pilot (Kvatro Telecom). Подобное совмещение обладает следующими преимуществами: сразу выявляются ошибки в тесте; имеется возможность генерировать тесты в процессе отладки; результаты теста сразу обрабатываются и в случае ошибки передаются отладчику, который интерактивно воспроизводит этот тест. Средства поддержки отладки могут закладываться на стадии написания исходного текста и компиляции. Во время написания исходного текста в программный продукт может закладываться псевдо-агент — набор функций, осуществляющих некоторые отладочные действия. Для отладки с использованием исходных текстов приложения, необходимо при компиляции генерировать дополнительную информацию, состоящую из описаний символов программы (переменные, функции, типы) и псевдо-символов, позволяющих отладчику определять адреса строк исходного текста, адреса секций, и т.д.
Модуль 3. ОБЗОР СОВРЕМЕННЫХ ОПЕРАЦИОННЫХ СИСТЕМ
ТЕМА 1. СЕМЕЙСТВО ОПЕРАЦИОННЫХ СИСТЕМ UNIX
UNIX является исключительно удачным примером реализации простой мультипрограммной и многопользовательской операционной системы. В свое время она проектировалась как инструментальная система для разработки программного обеспечения. Своей уникальностью система UNIX обязана во многом тому обстоятельству, что была, по сути, создана всего двумя разработчиками, которые делали ее исключительно для себя и первое время использовали на мини-ЭВМ с очень скромными вычислительными ресурсами. Первая версия этой системы занимала всего около 12 Кбайт и могла работать на компьютерах с очень небольшим объемом оперативной памяти. Поскольку при создании второй версии UNIX разработчики отказались от языка ассемблера и специально придумали язык высокого уровня, на котором можно было бы писать не только системные, но и прикладные программы (речь идет о языке С), то и сама система UNIX, и приложения, выполняющиеся в ней, стали легко переносимыми (мобильными). Компилятор с языка С для всех оттранслированных программ дает реентерабельный и разделяемый код, что позволяет эффективно использовать имеющиеся в системе ресурсы.
Дата добавления: 2018-08-06; просмотров: 351; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!