Отчеты о многопроцессорном покрытии
Я пытаюсь контролировать покрытие кода моего C++ проекта. Как я уже говорил в предыдущем вопросе, мне нужно использовать сопрограммы и другие расширенные функции C++2a, поэтому я использую clang++ скомпилировать это. Я обнаружил здесь, что можно использовать -coverage флаг при компиляции с clang++ (наряду с -O0 а также -g).
Наряду с исполняемым файлом, это производит .gcno файл, содержащий карту исполняемого файла. Когда исполняемый файл запущен, дополнительный .gcda генерируется файл, содержащий фактические данные профилирования.
Я заметил, что, если я запускаю исполняемый файл несколько раз, выходные данные покрытия корректно и правильно объединяются в .gcda файл, который очень хорош.
Теперь мне интересно, безопасно ли запускать одновременно несколько экземпляров исполняемого файла.
Прежде чем кто-либо предложит выполнить тест последовательно: я запускаю их последовательно, но мое приложение использует много сетей, и для некоторых тестов требуется несколько экземпляров для взаимодействия (я использую Docker для симуляции сети, и netem чтобы получить реалистичные сценарии ссылок).
Вызовет ли одновременный запуск нескольких экземпляров одного и того же исполняемого файла? Я могу себе представить, что если будет реализован какой-либо механизм блокировки, данные покрытия будут безопасно и атомарно записаны в .gcda файл, и если другие исполняемые файлы должны выполнить дамп, они будут ждать, пока снята блокировка. Однако я нигде не мог найти гарантии, что это действительно произойдет.
1 ответ
Профилирование GCOV должно быть многопроцессорным безопасным, начиная с Clang 7.
В Clang 6 было две ошибки, мешающие его работе: https://bugs.llvm.org/show_bug.cgi?id=34923 и https://bugs.llvm.org/show_bug.cgi?id=35464, но они сейчас исправлены.
Фактически, в настоящее время мы используем его для сбора данных покрытия для Firefox, который является многопроцессорным. У нас обоих есть несколько процессов в самом Firefox, и мы также запускаем тесты (для некоторых конкретных наборов тестов) параллельно.