Nano Hash - криптовалюты, майнинг, программирование

Использование __gcov_flush в библиотеке не заставляет другие модули создавать файлы .gcda.

В последнее время я пытался использовать gcc/gcov для тестирования покрытия кода для проекта C++. Проект состоит из своего основного модуля и нескольких библиотек .so, которые все должны быть приняты в расчет.

Я скомпилировал все модули с параметром --coverage, каждый с помощью gcc, и сохранил их там, где они были сгенерированы, вместе с соответствующими файлами тегов .gcno. После нормального выполнения и корректного выхода файлы .gcda могли быть правильно сгенерированы. Проблема в том, что программа должна быть службой без прерывания или завершения, и ей не разрешается вставлять какой-либо индивидуальный код (например, обработчик сигналов) в основной модуль. Как предлагают решения из Интернета, я написал функцию обработчика сигналов в автономной библиотеке .so, которая вызывает __gcov_flush при получении сигнала SIGUSR1 для сброса счетчиков покрытия во время выполнения в файлы. .

Однако было замечено, что хотя функция __gcov_flush гарантированно вызывается должным образом, во время выполнения создается только файл .gcda библиотеки .so. Мне кажется, что __gcov_flush отвечает за сброс данных модуля-оболочки, но не других. Интересно, так ли это должно работать, или есть какие-то хитрости, о которых мне нужно позаботиться, чтобы получить полные результаты?

27.01.2015

Ответы:


1

Я вижу здесь две проблемы.

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

  • Функция __gcov_flush() из libgcov.a объявлена ​​с __attribute__ ((__visibility__ ("hidden")))

Если извлечь _gcov.o из архива и запустить

objdump -t _gcov.o

ты видишь что-то вроде

   _gcov.o:     file format elf32-littlearm

   SYMBOL TABLE:
   000014b4 g     F .text  00000016 .hidden __gcov_flush

Линкер не экспортирует скрытые символы, даже если вы попросите его сделать это, как уже упоминалось здесь или здесь

Поэтому я вижу два решения второй проблемы.

  1. Вы можете попробовать отредактировать таблицу символов для _gcov.o в libgcov.a и установить видимость "default" вместо "hidden". Я не пошел по этому пути, потому что не нашел хорошего редактора эльфов.

    Если вам удалось это сделать, обязательно обновите команду ссылки, чтобы она связывала этот исправленный _gcov.o вместо стандартного из libgcov.a. По сути, для этого вам нужно удалить опцию --coverage из ваших флагов компоновщика.

  2. Вы можете создать оболочку для объявления __gcov_flush() и экспортировать ее, как это было предложено в приведенных выше ссылках. Вызовите эту оболочку из вашего обработчика сигналов в общей библиотеке.

    Я предлагаю вам не добавлять профилирование для небольшой библиотеки обработчиков сигналов - это действительно не нужно.

11.03.2015
Новые материалы

Кластеризация: более глубокий взгляд
Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..

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

Частный метод Python: улучшение инкапсуляции и безопасности
Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

Как я автоматизирую тестирование с помощью Jest
Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..

Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

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

Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..