Комментарии 13
С нетерпением жду разбора UE4.
А будет работать слежение за другими компиляторами? Каким-нибудь avr32-gcc например?
Во-первых, мониторинг перехватывает все вызовы компилятора.
Что-то мне это напоминает: blog.not-a-kernel-guy.com/2012/05/04/1317
Алексей, привет! Давно не общались. Буду рад услышать критику подхода и идеи по тому, как это сделать лучше.
Тут сложно критиковать по делу, так я не знаю как именно вы перехватываете вызовы компилятора. Наиболее беспролемный вариант, насколько я могу себе представить, — это подсунуть вместо компилятора (PATH поправить, например) proxy, который будет сначала делать свою работу, а потом вызывать исходный компилятор, чтобы собрать все как было. При таком подходе теряется минимум контекста — т.е. однозначно понятно, что именно требует система сборки от компилятора. Для контраста — перехват создания всех процессов компилятора уже работает хуже, так как вылезают проблемы если собираются несколько проектов сразу.
Даже при таком подходе правильная имитация компилятора — еше тот геморрой. Вечно вылезают разные тонкости. Добавление поддержки нового компилятора становится большой проблемой, так как приходится переписывать логику разбора параметров командной строки и т.п. В результате будут поддерживаться не все компилаторы, а два-три наиболее ходовых.
Поддержка произвольных систем сборки — тоже не подарок. Скажем ничего не мешает собрать один и тот же исходник с разными параметрами, причем может оказаться, что их всех собранных вариантов используется только один.
Мне нравится идея сделать так, чтобы все работало само. Если это будет работать в 95% реальных проектов и ладно. Если нет, то я бы ограничил разунмость перехватчика и попытался бы сделать так, чтобы добавление анализатора в проект хотя бы и требовало минимальных усилий, но за счет этого, разработчик мог явно объяснить анализатору, что от того требуется.
Даже при таком подходе правильная имитация компилятора — еше тот геморрой. Вечно вылезают разные тонкости. Добавление поддержки нового компилятора становится большой проблемой, так как приходится переписывать логику разбора параметров командной строки и т.п. В результате будут поддерживаться не все компилаторы, а два-три наиболее ходовых.
Поддержка произвольных систем сборки — тоже не подарок. Скажем ничего не мешает собрать один и тот же исходник с разными параметрами, причем может оказаться, что их всех собранных вариантов используется только один.
как это сделать лучше
Мне нравится идея сделать так, чтобы все работало само. Если это будет работать в 95% реальных проектов и ладно. Если нет, то я бы ограничил разунмость перехватчика и попытался бы сделать так, чтобы добавление анализатора в проект хотя бы и требовало минимальных усилий, но за счет этого, разработчик мог явно объяснить анализатору, что от того требуется.
Алексей, спасибо за подробный комментарий. Мне кажется с «заменой» компилятора есть проблема. Я сильно сомневаюсь, что поправить PATH достаточно для того, чтобы вызывался proxy-компилятор, но при этом не переставал работать основной компилятор.
По технологии — вот как это сделано у нас. Мы «читаем» процесс компилятора. Зная достаточно информации об окружении процесса целевого компилятора, можно выполнить препроцессирование с такими же параметрами компиляции. Для корректного запуска препроцессора необходимо знать следующую информацию о процессе:
• рабочая директория процесса
• полная строка запуска процесса (т.е. имя исполняемого файла и все аргументы, с которыми он был запущен)
• полный путь до исполняемого файла процесса
• системные переменные окружения процесса
Собираем эту информацию для каждого файла и в путь.
По технологии — вот как это сделано у нас. Мы «читаем» процесс компилятора. Зная достаточно информации об окружении процесса целевого компилятора, можно выполнить препроцессирование с такими же параметрами компиляции. Для корректного запуска препроцессора необходимо знать следующую информацию о процессе:
• рабочая директория процесса
• полная строка запуска процесса (т.е. имя исполняемого файла и все аргументы, с которыми он был запущен)
• полный путь до исполняемого файла процесса
• системные переменные окружения процесса
Собираем эту информацию для каждого файла и в путь.
Я сильно сомневаюсь, что поправить PATH достаточно для того, чтобы вызывался proxy-компилятор, но при этом не переставал работать основной компилятор.
Proxy должен вызывать оригинальный компилятор с немодифицированным окружением, само собой. Не две срочки кода, но и не сильно сложно.
Собираем эту информацию для каждого файла и в путь.
При таком может теряться информация о зависимостях между разными вызовами компилятора. Не факт, что оно вам нужно, правда.
Так же сложно определить к какому проекту относится каждый конкретный процесс.
Потенциально возможна проблема с генерируемыми файлами. В случае proxy, система сборки позаботится, что исходный файл не будет удален, пока оно нужен компилятору. В вашем случае — не факт.
Короче, я исхожу из того, что аххилесова пята любых подобных перехватчиков — недостаток контекстной информации о перехваченных операциях (что не дает трактовать их правильно) и изменение поведения перехваченных операций. В вашем случае — временные файлы, удаленные после сборки, повторные вызовы компилятора — будут сбивать анализатор с толку. Основное средство борьбы с обоими проблемами — постараться ничем не отличаться от исходного компилятора.
Нажимаете кнопку «Compiler Monitoring», где выбираете платформу x64 для мониторинга.
В версии PVS-Studio 5.19 (актуальной на текущий момент) такой кнопки в интерфейсе PVS-Studio нет.
Кнопка, запускающая мониторинг, которую имеет в виду автор, теперь «Analize your files...»:
UPD: В онлайн-документации все элементы интерфейса и последовательность действий указаны верно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PVS-Studio теперь поддерживает любую сборочную систему на Windows и любой компилятор. Легко и «из коробки»