Как анализировать C и C++ код без привязки к сборочной системе на Windows

• Что нужно?
• Как это работает?
• Использование CLMonitor.exe
  • Запуск мониторинга
  • Запуск анализа
  • Сохранение дампа мониторинга компиляции
  • Использование режима перехвата Wrap Compilers
• Использование плагина для Visual Studio Code
• Заключение

Пишете на C или C++ и хотите анализировать код независимо от используемой системы сборки? Рассказываем, как это сделать на Windows с помощью статического анализатора PVS-Studio и плагина для Visual Studio Code.

Код, написанный на C и C++, может использоваться для самых разных целей. И под каждые из этих целей есть свои инструменты сборки. Например, при разработке программного обеспечения для встраиваемых систем используются специальные компиляторы и сборочные системы.

Иногда бывает так, что появляется целый "зоопарк" самописных скриптов сборки, причём часто бывает так, что последний "смотритель" этого зоопарка уволился ещё в прошлом году (играет Гражданская Оборона — "Зоопарк").

Хотелось бы всё равно как-то анализировать такой код — без необходимости разбираться в хрупкой и непонятной системе сборки. Что же делать?

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

В этой статье посмотрим на то, как воспользоваться этим механизмом для ОС Windows в анализаторе PVS-Studio, а также о том, как сделать его использование в процессе разработки удобным.

Что нужно?

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

Во-первых, описанные далее инструкции работают только на ОС Windows. О том, как использовать схожий механизм для Linux, мы поговорим в другой статье.

Во-вторых, мониторинг компиляции PVS-Studio сможет отловить вызовы только поддерживаемых компиляторов: Visual C++, GCC, Clang, Keil MDK ARM Compiler 5/6, IAR C/C++ Compiler for Arm.

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

Кроме флагов компиляции, PVS-Studio также требуется промежуточный .i файл, который и является результатом работы препроцессора и содержит все включённые в исходный файл заголовки и раскрытые макросы.

PVS-Studio не имеет собственного препроцессора, поэтому при анализе полагается на внешний. Таким образом, PVS-Studio может улучшить качество анализа: мы анализируем код теми же инструментами, которыми вы их собираете.

Как это работает?

Сервер мониторинга (CLMonitor.exe) отслеживает запуск процессов, соответствующих целевому компилятору, и собирает информацию об окружении этих процессов. Эта информация необходима для дальнейшего запуска статического анализа и включает в себя:

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

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

Удобство такого механизма также состоит в том, что для анализа проекта достаточно просто запустить пересборку без необходимости как-либо модифицировать сборочные сценарии.

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

Использование CLMonitor.exe

Рассмотрим способы, как можно запустить сервер мониторинга CLMonitor.exe напрямую из консоли. Этот сценарий может быть удобен для интеграции статического анализа в автоматизированную систему сборки.

Сервер мониторинга необходимо запускать до непосредственной сборки проекта.

Запуск мониторинга

Чтобы запустить процесс мониторинга, необходимо выполнить следующую команду:

CLMonitor.exe monitor

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

Таким образом, запуск сервера не будет мешать, например, дальнейшей работе пайплайна в CI/CD. Кстати, о том, как интегрировать статический анализ в CI/CD, мы уже говорили в другой статье.

Раз ни одна консоль не подключена к процессу CLMonitor, то помимо стандартных потоков ввода/вывода (stdin и stdout), сервер мониторинга также выводит сообщения в журнал событий Windows (Event Viewer > Windows Logs > Application).

Можно отслеживать только те запуски компиляторов, которые были запущены от определённого процесса. Для этого нам необходимо запустить CLMonitor в режиме отслеживания с аргументами trace и ‑‑parentProcessID. Аргумент ‑‑parentProcessID в качестве параметра принимает PID того процесса, который и будет выступать родительским для запускаемых процессов компилятора:

CLMonitor.exe trace –-parentProcessID 10256

Если же мы выполняем сборку из консоли и хотим, чтобы сервер мониторинга отследил только сборку, запускаемую из этой же консоли, то можно запустить CLMonitor с аргументом ‑‑attach (-a):

CLMonitor.exe monitor –-attach

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

Запуск анализа

После сборки проекта нужно начать анализ. Для этого необходимо запустить подобную команду:

CLMonitor.exe analyze -l "D:\ptest.plog"

Аргумент -l в качестве параметра принимает полный путь до итогового файла отчёта анализатора.

Также при запуске анализа можно передать дополнительные параметры:

• с помощью флага -u можно передать путь до файла подавления (suppress-файла);
• с помощью флага ‑‑intermodular можно включить режим межмодульного анализа;
• с помощью флага -c можно передать путь до файла конфигурации анализа .pvsconfig.

Если же необходимо завершить мониторинг без запуска анализа, можно воспользоваться командой abortTrace:

CLMonitor.exe abortTrace

Сохранение дампа мониторинга компиляции

Сервер мониторинга CLMonitor позволяет сохранять отловленную информацию о компиляции в отдельном дамп-файле. Благодаря этому в дальнейшем можно запускать анализ без необходимости повторно собирать проект.

Файл дампа — это .zip архив, содержащий список отловленных у процессов параметров в формате XML. Можно запускать анализ как из заархивированного файла дампа, так и из неупакованного .xml-файла.

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

CLMonitor.exe saveDump -d "D:\monitoring.zip"

После флага -d необходимо указать путь до итогового файла дампа.

Также мы можем сразу запустить анализ из файла дампа с помощью подобной команды:

CLMonitor.exe analyzeFromDump -l "d:\ptest.plog" -d d:\monitoring.zip

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

Использование режима перехвата Wrap Compilers

Используемый в CLMonitor по умолчанию метод отслеживания запусков компиляторов, увы, может не успеть определить все файлы исходного кода. Подобная проблема особенно актуальна для embedded-проектов, поскольку они состоят из быстро компилирующихся файлов на языке C.

Для того, чтобы гарантировать перехват всех процессов компиляции, сервер мониторинга может использовать более агрессивный подход через механизм Image File Execution Options (IFEO) в Windows.

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

Работа этого режима прозрачна для сборочной системы и требует доступ к редактированию пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options в реестре Windows.

Чтобы запустить этот метод отслеживания в консольном варианте мониторинга, необходимо передать серверу мониторинга флаг ‑‑wrapCompilers (-W) со списком компиляторов, например:

CLMonitor.exe trace --wrapCompilers gcc.exe,g++.exe

Безопасность превыше всего!

Несмотря на все описанные преимущества использования механизма IFEO, стоит соблюдать некоторые меры предосторожности.

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

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

Использование плагина для Visual Studio Code

Ух! Сколько всего интересного мы уже рассмотрели. Однако это не всё.

Использование мониторинга компиляции из консоли не всегда может быть удобным способом, поэтому воспользоваться механизмом можно и с помощью UI. Здесь к нам на помощь приходит плагин PVS-Studio для среды разработки Visual Studio Code.

Он позволяет запускать анализ и просматривать отчёт анализатора, а с версии PVS-Studio 7.39 ещё и поддерживает мониторинг компиляции на Windows.

Для запуска мониторинга компиляции необходимо в палитре команд Visual Studio Code (Ctrl + Shift + P) выбрать команду PVS-Studio: Run compiler monitoring for C and C++.

При её запуске в окне плагина с таблицей появится индикатор того, что мониторинг запущен:

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

Также анализ можно запустить с помощью команды PVS-Studio: Stop monitoring and start analysis в палитре команд Visual Studio Code.

Если мы запускаем мониторинг на проекте впервые, плагин предложит отредактировать файл настроек ./.PVS-Studio/CLMonitorAnalyzerConfig.jsonc, в котором можно задать некоторые настройки анализа, идентичные настройкам консольной версии:

Нажав Edit, можно установить следующие параметры:

• путь до файла дампа мониторинга (по умолчанию ./.PVS-Studio/lastMonitoring.zip);
• путь до файла (директории с файлами) конфигурации анализа .pvsconfig.

Если же нажать Continue, то анализ запустится с заданными по умолчанию настройками.

Когда анализ закончится, предупреждения появятся в таблице окна плагина.

Если файлы исходного кода, а также конфигурация сборки не менялись, то мы можем воспользоваться файлом дампа и запустить анализ из него. Для этого необходимо выбрать команду PVS-Studio: Start analysis from compiler monitoring dump file в палитре команд Visual Studio Code.

Также в плагине PVS-Studio для Visual Studio Code мы можем воспользоваться режимом Wrap Compilers. Для этого на вкладке Monitoring (C and C++) в настройках плагина необходимо указать имена исполняемых файлов компиляторов, которые необходимо отслеживать:

Для работы мониторинга в этом режиме необходимо перезапустить Visual Studio Code с правами администратора.

Также в любом из режимов, если сборка проекта выполняется с правами администратора, Visual Studio Code тоже должен быть запущен с этими правами, чтобы сервер мониторинга смог отловить вызовы компиляторов.

Заключение

В этой статье мы рассмотрели, как можно воспользоваться механизмом мониторинга компиляции на Windows в анализаторе PVS-Studio.

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

О том, как перехватывать вызовы компиляторов на Linux, мы расскажем в нашем блоге чуть позже.

А если вы ещё не пользовались статическим анализатором PVS-Studio, то по этой ссылке можно получить бесплатную пробную версию, чтобы попробовать инструмент на своём проекте.

Чистого вам кода, друзья!