Clang Coverage Mapping с -fprofile-instr-generate

Question

Я пытаюсь сгенерировать отчет о покрытии кода для некоторых индивидуально скомпилированных тестов в Ubuntu 18.04 и сталкиваюсь со странной проблемой. Если я скомпилирую с помощью clang 5.0.0 и передам ему флаги -fprofile-instr-generate и -fcoverage-mapping, он действительно сработает, и запуск скомпилированного теста заставит его выплеснуть файл .profraw, который я могу обработать с помощью llvm-cov, и превратить в отчет о покрытии. Тем не менее, единственное покрытие, которое, кажется, отслеживается, - это тестовая программа и любой код, напрямую включенный через #include, полностью игнорирующий код, который был связан. Например, если заголовочный файл включен через #include, он покажет покрытие для этого файла, но не для связанного. c файла, в котором хранится фактический вызываемый код. Из некоторых исследований казалось, что решение было также добавьте -fprofile-instr-generate к шагу связывания, но это никак не изменило результат. Это ужасная практика (и неустойчивая) - вручную #include любые файлы, для которых я хочу увидеть покрытие, но я не вижу другой опции, которая позволяет мне просматривать покрытие связанного кода (в частности, покрытие функции, которую я использую). вызов в тестовом жгуте и все, что вызывает функция). Это проблема других людей, и кто-нибудь знает, как ее решить?

Answer 1

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

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

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

Однако, для компоновщика тоже нужны флаги.

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

Answer 2

Исправлена ​​собственная проблема! Оказывается, тест связывался с общей библиотекой .so, которая содержала мои целевые функции, поэтому проблема была решена с помощью двух вещей. Во-первых, инструментирование шага, на котором объекты .o компилировались в общую библиотеку, позволяло видеть целевые функции. Во-вторых, использование llvm-cov show / report с .profdata, сгенерированным тестом, и передача ему совместно используемой библиотеки в качестве двоичного файла вместо тестового двоичного файла позволили ему сообщать информацию о покрытии для целевых функций. Извлеченный урок, всегда проверяйте, импортирует ли ваш инструментальный тест разделяемые библиотеки, и убедитесь, что ваши разделяемые библиотеки компилируются с правильными флагами для их применения!