Используем версию среды разработки IDE Momentics под Windows. Отладка приложений будет выполняться на удалённой станции, функционирующей под управлением QNX. При такой реализации потребуется настроить менеджер сети на работу с протоколом TCP/IP для связывания инструментальной и целевой платформ. Для выполнения распределенного приложения под управлением QNX будут передаваться пакеты сети QNet.
Настройка сети QNet
При настройке сети сначала необходимо активировать драйвер сетевого адаптера. В QNX 6.3.2 по-умолчанию используется протокол TCP/IP, поэтому после запуска требуется только присвоить IP-адрес и маску подсети. Далее требуется активировать процесс, обслуживающий протокол QNet и выделить ему сокет, через который будет производиться обмен с IDE на удалённом компьютере. Скрипт, выполняющий указанные функции приведён ниже:
mount -T io-net /fs/hd0-dos/QNX_data/drivers/devn-rtl8169.so
ifconfig en0 10.1.208.2 netmask 255.255.255.224
mount -T io-net -o do_crc=1 npm-qnet.so
SOCK=/net/EA38f626 qconn
Вторая строка скрипта должна быть заполнена в соответствии с сетевыми настройками и адресами, полученными у администратора или отображенными в configurations>network>…в графическом интерфейсе или полученными посредством утилит ping, ifconfig, net и др. Для нашей лаборатории IP адреса учебных компьютеров лежат в диапазоне 10.1.208.2 – 10.1.208.21, а маска составляет 255.255.255.224
Если рабочая станция используется только как отладочный сервер, то данный код можно записать в файл автозапуска (для текущих лабораторных исследований в этом нет необходимости). После этого требуется задать имя сервера отладки в сети в файле “/etc/syste/hosts”. Пример приведён ниже:
10.1.208.2 debug_server localhost
После настройки в корневом директории должен появиться каталог /net и в нём папка debug_server. Это будет свидетельствовать о том, что удалённый доступ через QNet настроен верно. После этого можно перейти к созданию проекта в среде QNX Momentics.
Если папка уже доступна в файловой системе, и вы можете видеть в ней файловые системы других компьютеров, включенных в данный момент и подсоединенных к сети, то необходимости в запуске указанного скрипта нет, за исключением запуска утилиты qconn и задания имени сервера отладки.
Создание проекта в QNXMomentics
При создании проекта требуется указать его имя, рабочий директорий, целевую архитектуру и инструменты анализа. Для отладки следует выбрать опцию debug. Среда QNX Momentics позволяет одновременно выбирать несколько режимов сборки проекта, однако не все инструменты могут работать одновременно с несколькими режимами.
Рис. 2. Окна создания проекта
После настройки проекта будет открыт редактор, в котором производится разработка. Функциональность и мнемоника данного режима соответствует аналогичным IDE, что упрощает освоение QNX Momentics.
Отладка в QNXMomentics
В IDE существуют несколько программ и режимов отладки, однако использование инструментов анализа (например, средство профилирования) возможно только при удалённой отладке при помощи QNX GDB (Debugger). Формально, допустимо назначать удалённым сервером компьютер, на котором ведётся разработка, но это может приводить к высокой загрузке системы и, как следствие, искажению получаемых данных. При запуске отладки следует указать исполняемый файл и удалённый сервер.
В нашем примере был задан сервер 10.1.208.2, на котором ранее была произведена настройка QNet. После установки связи с сервером возможна отладка приложения.
Далее в опции Tools окна настроек отладки выбираем средство профилирования Profiling Tool. Убедитесь, что отладка работает корректно и в окне средства профилирования можно видеть распределение процессорного времени по потокам (см. рис. 3).
Рис. 3. Результаты профилирования программы
Использование средств трассировки для временного анализа системы
Средства трассировки процессов доступны только для отладки на удалённых серверах. При использовании в качестве сервера компьютера, на котором ведётся разработка, временные характеристики искажаются. Как и в предыдущих пунктах, разработка ведётся в ОС Windows, а для отладки используется сервер QNX, подключенный по протоколу QNet.
Для взаимодействия с удалённым сервером используется окно Target Navigator (рис. 4), в котором отображается информация о запущенных на сервере процессах. Через него также вызывается трассировщик событий Kernel Event Trace (рис. 5).
В настройках трассировщика событий можно задавать сервер, время и частоту сбора данных, задавать типы собираемой информации и многое другое. Однако, данные собираются обо всех процессах в системе.
Для того, чтобы получить информацию об отдельном процессе, используется System Information Logger, но он не позволяет получать временные диаграммы выполнения процессов.
Рис. 4. Окно Target Navigator
Результаты трассировки сохраняются в файл-отчёт, который может быть просмотрен в различных представлениях при помощи IDE.
Рис. 5. Окна настройки трассировщика
Трассировка системы в QNX Momentics не синхронизирована с процессом отладки, поэтому чтобы наблюдать процессы в трассировщике иногда требуется перед отключением потоков в программе устанавливать задержку (до 10000 секунд). Время наблюдения необходимо подбирать и регулировать масштабированием.
Рис. 6. Результаты трассировки незагруженной системы
(Время наблюдения было взято равным 20 секундам).
Перед анализом разработанной программы бывает полезно провести трассировку незагруженной системы. Пример приведен на (рис.6 ):
Трассировка показала, что системное и служебное программное обеспечение занимает около 0.7% процессорного времени. По сравнению с операционными системами общего назначения (до 10% процессорного времени на том же компьютере), данный показатель очень мал и свидетельствует об ориентации QNX на менее производительные промышленные ВС.
Кроме статистики загрузки процессора, сети и дисковых носителей, трассировщик позволяет строить временную диаграмму состояний процессов и потоков в системе (рис. 7.). Это позволяет в случае необходимости оценить порядок выполнения потоков.
Рис. 7. Временная диаграмма работы процессов
Перед трассировкой различных режимов целесообразно рассмотреть загрузку процессора при выполнении пользовательского приложения.
Рис. 8. Результаты трассировки загруженной системы
Очевидно, что пользовательский процесс полностью занимает свободное процессорное время. В данном случае это вызвано тем, что работа дочерних потоков не требует никаких дополнительных ресурсов, и потоки всегда находятся в очереди готовых.
Рис. 9. Пример
временной диаграммы
Временная диаграмма показывает, что каждые пять секунд второй поток переходит в активное состояние на одну секунду. После этого, его ресурс времени истекает, и он уступает место третьему потоку с приоритетом 8. Первый (родительский) поток при этом находится в блокировке с состоянием NANOSLEEP.
Рис. 10. Временная диаграмма с демонстрацией qconn
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.
