Анализ кода предполагает выполнение программ на реальном или виртуальном процессоре

Некоторое время назад я готовил / проводил семинар в рамках сертификации компании на соответствие стандарту PA DSS ( http://en.wikipedia.org/wiki/PA-DSS ). Одним из требований, предъявленных аудитором, было использование при разработке ПО автоматизированных инструментов анализа программного кода. Конкретной темой моего семинара был статический анализ и его возможности.

Теперь я хочу поделиться собранным материалом.
СТАТИЧЕСКИЙ АНАЛИЗ КОДА: ЧТО ЭТО ТАКОЕ?

В основном, определения и термины, от общих к частным. Это позволит в дальнейшем лучше понимать суть материала.

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

В случае анализа ПО объектом исследования является программное обеспечение как совокупность программ, процедур, правил и относящихся к их эксплуатации документов.

Занятие 8 (2022-23): Микроархитектура однотактового процессора SCHOOLRISCV

На программу можно просто смотреть, а можно её запустить. Соответственно, анализ ПО может быть статическим и динамическим.

Динамический анализ кода (англ. dynamic code analysis ) – анализ, проводимый при помощи выполнения программ на реальном или виртуальном процессоре. Утилиты динамического анализа могут требовать загрузки специальных библиотек, перекомпиляцию программного кода. Некоторые утилиты могут инструментировать исполняемый код в процессе исполнения или перед ним. Для большей эффективности динамического анализа требуется подача тестируемой программе достаточного количества входных данных, чтобы получить более полное покрытие кода . Также требуется позаботиться о минимизации воздействия инструментирования на исполнение тестируемой программы (включая временные характеристики).

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

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

Основные задачи динамического анализа: обнаружение ошибок памяти, выделение и освобождение памяти, memleaks , ситуации гонки потоков и взаимоблокировок, стэки вызовов и пр.

Статический анализ кода: Что? Как? Зачем? / Максим Стефанов

Статический анализ кода (англ. static code analysis ) – анализ ПО, производимый без реального выполнения исследуемых программ. В большинстве случаев анализ производится над какой-либо версией исходного кода, хотя иногда анализу подвергается какой-нибудь вид объектного кода (например, P -код).

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

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

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

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

В ЧЁМ ПОЛЬЗА?

Очевидно, чтобы начать использовать что-то новое, оно должно быть полезным. Далее – немного о профите от SCA .

Чем раньше ошибка в коде приложения будет обнаружена, тем дешевле стоит её исправление. Отсюда следует вывод, что наиболее дёшево и просто ошибка может быть устранена в процессе написания кода. А ещё лучше, если ошибка вовсе не будет написана.

Вот только захотел сделать ошибку, так сразу хлоп себя по рукам – и код написан уже правильно. Но так как-то не получается. Подход «надо писать без ошибок» всё равно не работает .

Даже высококвалифицированный программист, который никуда не торопится, совершает ошибки, начиная от простейших опечаток и заканчивая логическими ошибками в алгоритмах. Здесь срабатывает закон больших чисел. Вот вроде бы в каждом конкретном операторе « if » сделать ошибку невозможно. Но на 200, 500, 1000 примеров – одна ошибка да и найдётся.

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

Обычно самым первым уровнем обороны от ошибок является создание юнит-тестов на вновь написанный код. Иногда тесты пишутся ещё до кода, который они будут проверять ( test driven development ). Однако у юнит-тестов есть свой ряд недостатков, которые я не буду подробно рассматривать, т. к. они и так известны программистам.

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

Часто программисты пренебрегают ещё более ранним уровнем обороны – статическим анализом кода. Многие используют возможности анализа кода, не выходя за рамки диагностических предупреждений, выдаваемых компиляторами. А между тем существует целый класс инструментов, позволяющих выявить на этапе кодирования значительный процент логических ошибок и простых опечаток. Эти инструменты осуществляют более высокоуровневую проверку кода, опираясь на знание некоторых паттернов кодирования, используют эвристические алгоритмы, имеют гибкую систему настройки.

У статического анализа, конечно тоже, есть недостатки. Многие виды ошибок он просто не в состоянии обнаружить. Анализаторы дают ложные срабатывания и заставляют вносить в код такие правки, чтобы этот код им понравился и был затем оценен как безопасный .

Но есть и огромные преимущества. Анализ покрывает все ветвления программы, вне зависимости от частоты их использования. Анализ не зависит от этапа исполнения. Вы имеете возможность проверить даже недописанный код. Вы можете проверить большой объём кода, доставшийся вам по наследству. Статический анализ быстр и хорошо масштабируется в отличие от инструментов динамической проверки .

Т. о., польза от применения статического анализа кода – более раннее обнаружение и устранение дефектов кодирования .

Наличие исходных кодов программы существенно упрощает поиск уязвимостей. Вместо того, чтобы вслепую манипулировать различными параметрами, которые передаются приложению, куда проще посмотреть в программном коде, каким образом она их обрабатывает. Скажем, если данные от пользователя передаются без проверок и преобразований, доходят до sql -запроса – имеем уязвимость типа sql injection . Если они добираются до вывода в html -код – получаем классический xss . От статического анализатора требуется чётко обнаруживать такие ситуации, но, к сожалению, выполнить это не всегда так просто, как кажется .

ЧТО МОЖНО ОБНАРУЖИТЬ?

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

• Явные случаи неопределённого поведения: неинициализированные переменные, обращение к null -указателям и т. д.

int x;
int y = x + 2; // variable «x» might not have been initialized

• Нарушение схемы использования ресурса. Например, для каждого open нужен close . И если файловая переменная теряется раньше, чем файл закрывается, анализатор может сообщить об ошибке.
• Типичные сценарии, приводящие к недокументированному поведению. Стандартная библиотека языка Си известна огромным количеством неудачных технических решений. Некоторые функции, например, gets , в принципе небезопасны. sprintf и strcopy безопасны лишь при определённых условиях. И, например, статический анализатор может обратить внимание программиста на такой код:

void doSomething (const char* x) <
springf(s. «[%s]», x); // sprintf в локальный буфер, возможно переполнение

• Сценарии, мешающие кроссплатформенности.

Object *p = getObject();

int pNum =reinterpretCast(p); // на x86-32 верно, на x64 часть указателя будет потеряна, нужен size_t

• Прочие ошибки по невнимательности. Например, многие функции из стандартных библиотек не имеют побочного эффекта, и вызов их как процедур не имеет смысла. Так что ошибочным будет код.

std::string s;
s.empty(); //вероятно, вы хотели s.clear()?

• Ошибки, возникающие при копировании кода. Да-да, многие (все) разработчики иногда копируют частично повторяющиеся фрагменты – не пишут с нуля, а размножают и исправляют. Получаются ошибки наподобие:

dest.x = src.x + dx;
dest.y = src.y + dx; // ошибка, надо dy!

• Неизменный параметр, передаваемый в функцию. Иногда подобные «брошенные» параметры – признаки изменившихся требований к программе: когда-то параметр был задействован, но сейчас он уже не нужен. В таком случае разработчик может вообще избавиться от этого параметра и от связанной с ним логики.

void doSomething (int n, boolean flag) < // flag всегда равен true
// какая-то логика
// код есть, но не задействован
doSomething (n, true);
doSomethig (10, true);
doSomethig(x.size(), true);

Нужно отметить, что большинство современных компиляторов выводят сообщения о том, что код, будучи формально правильным, скорее всего, содержит ошибку. Это тоже простейший статический анализ. Но у компилятора есть много других немаловажных характеристик – скорость работы, качество машинного кода, удобство… Да и «зашумлять» консоль ложными тревогами – не самое удачное решение. Поэтому компиляторы проверяют код лишь на простейшие, очевидные ошибки. А для более серьёзного исследования кода есть специализированное ПО, запускаемое не постоянно, а лишь время от времени.

КАК ЭТО ДЕЛАЕТСЯ?
Доверяй, но понимай. Вопрос в том, как же выполняется статический анализ.

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

Источник: itech-notes.blogspot.com

ИУС_РК2

статическое, текстовое, удобочитаемое, исполняемое описание компьютерной программы, которое может быть скомпилировано автоматически в исполняемый код. Анализ исходного кода включает три компонента: • Парсер (parser) , который выполняет синтаксический разбор исходного кода и преобразует результаты анализа в одну или несколько форм внутреннего представления.

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

Некоторые внутренние представления создаются непосредственно парсерами, другие требуют результатов предыдущего анализа. Классическими примерами таких представлений является граф потоков управления (control-flow graph, CFG), дерево вызовов (call graph), абстрактное синтаксическое дерево (abstract syntax tree, AST), форма статического единственного присваивания (static single assignment, SSA). • Анализ внутреннего представления . Анализ может производится по о Статический или динамический.

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

Результаты такого анализа более точные, но гарантируются только для конкретных входных данных. Утилиты динамического анализа могут требовать загрузки специальных библиотек или даже перекомпиляцию программного кода. о Контекстно-зависимый (context-sensitive) межпроцедурный анализ. о Потоково-зависимый (flow-sensitive) анализ. Кроме того, анализаторы кода можно классифицировать следующим образом. • Автоматические анализаторы, которые проверяют исходный код в соответствии с предопределенным набором правил и по результатам проверки создают отчеты. • Различные виды браузеров, которые визуализируют структуру (архитектуру) ПО, таким образом, помогают лучше ее понять. 6.4. Примеры инструментальных систем для отладки Инструментальные средства Keil Software Инструментальные средства Keil Software, входящие в пакет uVision, позволяют производить отладку микроконтроллерных систем с помощью симулятора и

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

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

С помощью программы PONTiFLEX фирмы Adapted Solutions возможно объединение симулятора или отладчика, входящего в пакет uVision с MATLAB/Simulink. Симулятор электронных схем Симуляторы электронных схем, такие как Multisim фирмы National Instruments Electronics Workbench Group и Proteus фирмы Labcenter Electronics позволяют не только отлаживать цифровые и аналоговые схемы, но и отлаживать программы совместно с аппаратурой.

В состав программных пакетов входит несколько моделей различных микроконтроллеров, в которые можно загружать программы и исполнять их в непрерывном, пошаговом режиме или до точки остановки. С помощью виртуальных приборов, таких как вольтметр, амперметр, анализатор I2C, осциллограф, логический анализатор и генератор сигналов можно создать тестовые сигналы и посмотреть результаты работы схемы. Инструментальные средства отладки ОС РВ eCos В ОС РВ eCos для отладки ПО используется Redboot. Redboot (акроним от «Red Hat Embedded Debug and Bootstrap») — это приложение с открытым исходным кодом, которое использует слой абстракции оборудования (HAL) операционной системы реального времени eCos для загрузки программного обеспечения или прошивки (firmware) во встроенных вычислительных системах. Redboot предоставляется под GPL-совместимой лицензией eCos License. Redboot предоставляет широкий набор инструментов для загрузки и исполнения программ в целевых встроенных системах, в том числе Embedded Linux и eCos приложений, через последовательный канал или Ethernet соединение, а также

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

Возможности Redboot: 1. поддержка загрузочных скриптов; 2. простой интерфейс командной строки для управления и конфигурирования Redboot, доступный через последовательный канал или Ethernet соединение по протоколу telnet; 3. встроенные заглушки GDB для соединения с отладчиком на хост-машине через последовательный или сетевой Ethernet интерфейс (ограничивается локальной сетью) для отладки приложений на целевой встроенной системе; 4. атрибутная конфигурация — пользовательский контроль и возможность изменения таких аспектов, как системное время и дата (если используется), статический IP адрес и т.д.; 5. конфигурируемый и расширяемый, специально для адаптации под целевую платформу; 6. поддержка загрузки по сети, включая установку и загрузку через BOOTP, DHCP и TFTP; 7. поддержка загрузки программ через последовательный интерфейс посредством протоколов XModem и YModem; 8. само — тестирование при запуске 9. хотя Redboot является ответвлением от eCos, он может быть использован в качестве общей системы отладки и контроля загрузки программного обеспечения для любых встроенных систем и операционных систем. Например, с соответствующими дополнениями Redboot может заменить широко используемые программы BIOS персональных компьютеров. Симулятор Armulator Armulator является симулятором для процессорных ядер ARM. Armulator позволяет симулировать память, регистры, контроллер прерываний, таймер. Одной из основных особенностей Armulator является открытая архитектура, позволяющая самостоятельно реализовывать необходимые модели периферийных модулей.

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

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

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

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

Управление питанием этих схем может осуществляться через выводы микроконтроллера. 7.2. Уменьшение тактовой частоты микроконтроллера Уменьшение тактовой частоты процессора является одним из самых простых способ уменьшения энергопотребления. В зависимости от типа микроконтроллера может быть достигнуто снижение потребляемой мощности в единицы — десятки раз.

Уменьшение энергопотребления происходит из-за уменьшения числа переключений, производимых транзисторными каскадами в микроконтроллере. Энергопотребление одних схем в большей степени зависит от частоты, других — в меньшей. Поэтому характер зависимости энергопотребления от частоты зависит от типа микроконтроллера, количества включенных в нем блоков, настройки портов ввода-вывода и внешней нагрузки.

Таблица 7. Примерные значения потребляемой мощности для двух различных частот тактового генератора

Микроконтроллер	f1/P		f2/P
Motorola 68HC705KJ1	1,0 МГц/ 4,0 мВт		2,1 МГц / 4.6 мВт
Microchip PIC 18	32	кГц / 3 мВт	40	Мгц/60 мВт
Philips LPC 9xx (MCS51)	12	МГц/25 мВт	18	МГц/40 мВт
Philips LPC 2292 (ARM7)	10	МГц/13 мВт	60	МГц/90 мВт

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

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

В режиме сна тактирование микроконтроллера прекращается, выполнение программы останавливается, энергопотребление становится минимальным. Выход из этого режима возможен в следующих случаях: • при выключении и последующем включении питания; • по сигналу RESET, в том числе, вырабатываемым сторожевым (wtachdog) таймером; • при возникновении не запрещенного прерывания.

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

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

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

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

Микроконтроллер	Обычный режим		Режим сна
Motorola 68HC705KJ1	4,0 мВт		1.0 мВт
Atmel mega 128	33	мВт	75 мкВт
Microchip PIC	20	мВт (20 МГц)	10 мкВт
TI MSP 430	3 мВт		15 мкВт
STMicroelectronics	150 мВт (48 МГц)		33 мкВт
ARM7

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

Микроконтроллер состоит из множества блоков, многие их которых можно включать и выключать (контроллеры UART, CAN, I2C, ЦАП, АЦП, таймеры и т.д.). Если неиспользуемые блоки выключить, то энергопотребление уменьшится. 7.5. Конфигурирование портов ввода-вывода Необходимо помнить, что от конфигурации портов ввода-вывода зависит не только энергопотребление, но и работоспособность схемы.

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

Цифровые порты ввода Минимальное потребление на цифровых входах микроконтроллера будет в том случае, если напряжение на входе близко к нулю или к напряжению питания. Если напряжение на цифровом входе постоянно меняется или находится между точками ноль-питание, то лучше перевести порт на выход, если это позволяет схема. Необходимо помнить, что если два выхода работающих на вывод соединить вместе, то это может привести к выходу из строя портов. Соединять вместе можно только выходы с открытым коллектором. Цифровые порты вывода

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

энергопотребления нужно подать такой сигнал на выход порта, чтобы ток через нагрузку был минимальным. Аналоговый порт ввода (АЦП) АЦП имеют высокое входное сопротивление и поэтому потребляемый ток аналоговых входов весьма низок. Минимальное потребление энергии наблюдается в тех случае, когда напряжение входного сигнала находится в середине между нулем и напряжением питания. В ряде случаев выгодно переводить входные порты в аналоговый режим работы для уменьшения энергопотребления

Источник: studfile.net

Динамический анализ программ

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

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

Типы динамического анализа

Покрытие кода

Вычисление покрытия кода в соответствии с набор тестов или рабочая нагрузка — это стандартный метод динамического анализа.

• Gcov — программа покрытия исходного кода GNU.
• VB Watch внедряет код динамического анализа в программы Visual Basic для отслеживания покрытия кода, стека вызовов, трассировки выполнения, экземпляров объектов и переменные.

Обнаружение ошибок памяти

• AddressSanitizer : обнаружение ошибок памяти для Linux, OSX, Windows и других. Часть LLVM.
• BoundsChecker : обнаружение ошибок памяти для приложений на базе Windows. Часть Micro FocusDevPartner.
• Dmalloc, библиотеки для проверки распределения памяти и утечек. Программное обеспечение необходимо перекомпилировать, и все файлы должны включать специальный файл заголовка C dmalloc.h.
• Purify : в основном обнаружение повреждения памяти обнаружение и обнаружение утечки памяти.
• Valgrind запускается программы на виртуальном процессоре и могут обнаруживать ошибки памяти (например, неправильное использование malloc и free ) и состояния гонки в многопоточных программах.

Локализация ошибки

Локализация ошибки относится к обнаружению ошибочного кода (например, ошибки в заявлении) в соответствии с неудачными и успешными тестовыми примерами. Например, Tarantula — это хорошо известный подход к локализации неисправностей, основанный на покрываемом коде. Локализация сбоев иллюстрирует важное свойство динамического анализа: результаты анализа зависят от рассматриваемой рабочей нагрузки, входных данных или тестовых примеров. Для локализации неисправностей было показано, что можно провести рефакторинг тестовых примеров для получения лучших результатов.

Инвариантный вывод

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

Анализ безопасности

Динамический анализ может использоваться для обнаружения проблем безопасности.

• IBM Rational AppScan — это набор решений безопасности приложений, предназначенных для различных этапов жизненного цикла разработки. Пакет включает два основных продукта динамического анализа — IBM Rational AppScan Standard Edition и IBM Rational AppScan Enterprise Edition. Кроме того, в комплект входит IBM Rational AppScan Source Edition — инструмент статического анализа.

Ошибки параллелизма

• ParasoftJtest использует обнаружение ошибок времени выполнения для выявления таких дефектов, как состояния гонки, исключения, утечки ресурсов и памяти, а также уязвимости атак безопасности.
• Intel Thread Checker — это инструмент анализа ошибок потоковой передачи во время выполнения, который может обнаруживать потенциальные гонки данных и взаимоблокировки в многопоточном Windows или Приложения Linux.
• Intel Parallel Inspector выполняет потоки выполнения и анализ ошибок памяти в Windows.
• ParasoftInsure ++ — это средство анализа памяти и обнаружения ошибок во время выполнения. Его компонент Inuse обеспечивает графическое представление распределения памяти с течением времени, с конкретной видимостью общего использования кучи, выделения блоков, возможных невыполненных утечек и т. Д.

Срезы программы

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

Анализ производительности

Большинство инструментов анализа производительности используют методы динамического анализа программ.

• Prism от CriticalBlue — это инструмент, который динамически отслеживает программные приложения во время выполнения и собирает данные, которые можно использовать для анализа и выявления причин низкой производительности.

Методы

Большинство методов динамического анализа основаны на каком-то инструментарии кода или преобразовании.

• DynInst — это библиотека для исправления кода среды выполнения, которая полезна при разработке зондов динамического анализа программ и их применении к скомпилированным исполняемым файлам. Dyninst не требует исходного кода или перекомпиляции в целом, однако исполняемые файлы без удаления и исполняемые файлы с отладочными символами легче инструментировать.
• Iroh.js — это библиотека анализа кода времени выполнения для JavaScript. Он отслеживает путь выполнения кода, предоставляет слушателей времени выполнения для прослушивания определенных шаблонов исполняемого кода и позволяет перехватывать и управлять поведением выполнения программы.

См. Также

• Абстрактная интерпретация
• Daikon
• Тестирование динамической нагрузки
• Профилирование (компьютерное программирование)
• Проверка во время выполнения
• Анализ программ (информатика)
• Статический анализ кода
• Тестирование временных разделов

Источник: alphapedia.ru