10.3 Использование gcov с оптимизацией GCC ¶

Если вы планируете использовать gcov для оптимизации кода, необходимо сначала скомпилировать программу с помощью специального параметра GCC «--coverage». Помимо этого, вы можете использовать любые другие параметры GCC; но если вы хотите убедиться, что каждая строка вашей программы была выполнена, не следует компилировать с оптимизацией. В некоторых системах оптимизатор может исключить некоторые простые строки кода, объединив их с другими строками. Например, код такого вида:

if (a != b)
  c = 1;
else
  c = 0;

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

100:   12:if (a != b)
100:   13:  c = 1;
100:   14:else
100:   15:  c = 0;

Вывод показывает, что этот блок кода, объединённый оптимизацией, был выполнен 100 раз. В некотором смысле этот результат верен, поскольку была только одна инструкция, представляющая все четыре строки. Однако вывод не указывает, сколько раз результат был 0 и сколько раз 1.

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

Если функция не встроена, компилятор должен сгенерировать внестрочную копию функции в любом объектном файле, который её требует. Если файлы fileA.o и fileB.o оба содержат внестрочные тела определённой встраиваемой функции, они также оба будут содержать счётчики покрытия для этой функции. Когда файлы fileA.o и fileB.o связываются вместе, компоновщик на многих системах выберет одно из этих внестрочных тел для всех вызовов этой функции и удалит или проигнорирует другие. К сожалению, он не удалит счётчики покрытия для неиспользуемого тела функции. Следовательно, при инструментировании все, кроме одного, использования этой функции будут показывать нулевые значения.

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

Приложения с длительным временем выполнения могут использовать средства __gcov_reset и __gcov_dump для ограничения сбора профиля областью программы, представляющей интерес. Вызов __gcov_reset(void) обнулит все счётчики профиля, а вызов __gcov_dump(void) вызовет выгрузку собранной в этот момент информации профилирования в выходные файлы .gcda. Инструментированные приложения используют статический деструктор с приоритетом 99 для вызова функции __gcov_dump. Таким образом, __gcov_dump выполняется после всех пользовательских статических деструкторов, а также обработчиков, зарегистрированных с помощью atexit. Если исполняемый файл загружает динамическую общую объектную библиотеку с помощью функции dlopen, необходим параметр -Wl,--dynamic-list-data для выгрузки всех данных профилирования.

Отчёты профилирования библиотеки выполнения сообщают о различных ошибках, связанных с обработкой профиля и сохранением профиля. Ошибки выводятся в стандартный поток ошибок или в файл ‘GCOV_ERROR_FILE’, если используется переменная окружения. Для немедленного завершения после возникновения ошибки задайте переменную окружения ‘GCOV_EXIT_AT_ERROR’. Это может помочь пользователям найти конфликты профилирования, которые приводят к ошибочному профилю.