Информация

Дата основания
2008
Местоположение
Россия
Сайт
www.viva64.com
Численность
31–50 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 13
Собственно, мы его уже посмотрели. Но хотим совместить статью с выходом новой версии PVS-Studio. А то получится, что мы хвалим механизм, который ещё не доступен. Возможно некоторые захотят сразу попробовать и будут расстроены.
А будет работать слежение за другими компиляторами? Каким-нибудь avr32-gcc например?
А будет работать слежение за другими компиляторами?

Да!

Каким-нибудь avr32-gcc например?


Ну конкретно avr не обещаем, но на gcc classic пока нормальные результаты.
Алексей, привет! Давно не общались. Буду рад услышать критику подхода и идеи по тому, как это сделать лучше.
Тут сложно критиковать по делу, так я не знаю как именно вы перехватываете вызовы компилятора. Наиболее беспролемный вариант, насколько я могу себе представить, — это подсунуть вместо компилятора (PATH поправить, например) proxy, который будет сначала делать свою работу, а потом вызывать исходный компилятор, чтобы собрать все как было. При таком подходе теряется минимум контекста — т.е. однозначно понятно, что именно требует система сборки от компилятора. Для контраста — перехват создания всех процессов компилятора уже работает хуже, так как вылезают проблемы если собираются несколько проектов сразу.

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

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

как это сделать лучше


Мне нравится идея сделать так, чтобы все работало само. Если это будет работать в 95% реальных проектов и ладно. Если нет, то я бы ограничил разунмость перехватчика и попытался бы сделать так, чтобы добавление анализатора в проект хотя бы и требовало минимальных усилий, но за счет этого, разработчик мог явно объяснить анализатору, что от того требуется.
Алексей, спасибо за подробный комментарий. Мне кажется с «заменой» компилятора есть проблема. Я сильно сомневаюсь, что поправить PATH достаточно для того, чтобы вызывался proxy-компилятор, но при этом не переставал работать основной компилятор.

По технологии — вот как это сделано у нас. Мы «читаем» процесс компилятора. Зная достаточно информации об окружении процесса целевого компилятора, можно выполнить препроцессирование с такими же параметрами компиляции. Для корректного запуска препроцессора необходимо знать следующую информацию о процессе:

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

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


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

Собираем эту информацию для каждого файла и в путь.


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

Так же сложно определить к какому проекту относится каждый конкретный процесс.

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

Короче, я исхожу из того, что аххилесова пята любых подобных перехватчиков — недостаток контекстной информации о перехваченных операциях (что не дает трактовать их правильно) и изменение поведения перехваченных операций. В вашем случае — временные файлы, удаленные после сборки, повторные вызовы компилятора — будут сбивать анализатор с толку. Основное средство борьбы с обоими проблемами — постараться ничем не отличаться от исходного компилятора.
Спасибо за комментарий, будем учитывать это.
Нажимаете кнопку «Compiler Monitoring», где выбираете платформу x64 для мониторинга.


В версии PVS-Studio 5.19 (актуальной на текущий момент) такой кнопки в интерфейсе PVS-Studio нет.
Кнопка, запускающая мониторинг, которую имеет в виду автор, теперь «Analize your files...»:
image
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.