Отладочный трассировка C/C++

Я ищу бесплатную кросс-платформенную систему ведения отладочных журналов – которую вы использовали в течение нескольких лет и можете порекомендовать на основе собственного опыта.

Обязательно

• бесплатно, с разрешительной лицензией (например, предпочитаю MIT перед GPL (что тоже приемлемо))
• интерфейс C / C++
• разные уровни трассировки, например, информация, предупреждение, ошибка и т.д.
• можно легко скомпилировать так, чтобы не генерировать код (например, с помощью #ifdef)
• не менее одного пользовательского квалификатора для каждой трассировки. Например, подсистема / идентификатор потока
• последовательный формат, легко парсится пользовательскими скриптами
• автоматическое ведение файла и номера строки для каждого элемента трассировки
• автоматическая временная метка для каждой записи
• зрелая, стабильная и хорошо задокументированная + поддерживаемая
• нет проблем с многопоточностью, предпочтительно автоматическое ведение идентификатора потока
• простой и легкий для включения в проект (предпочитаю один #include, без необходимости задавать путь #include)

Хорошо бы иметь

• вывод через последовательный порт, а также в stdout
• тип элемента трассировки (например, интерфейс, доступ к базе данных, распределение/освобождение памяти)
• автоматическая генерация подробной информации об исключениях
• возможность дампа структур данных, а не только простых типов данных
• то же самое для массивов
• то же самое для вложенных структур, дамп в каком-либо виде дерева
• команда для трассировки размера стека
• и обратная трассировка стека (через несколько лет, мне интересно, что это на самом деле означает 😉
• и свободная/используемая память
• зашифрованный вывод, расшифровываемый по паролю
• много бесплатных инструментов постобработки (смотрите ниже)
• выбор вывода (экран, файл, TCP/UDP …)
• настройка уровней трассировки изнутри кода во время выполнения

Лично я кодировал многие из этих систем на протяжении десятилетий и оставлял их позади, меняя компании. Я склонен писать скрипты для постобработки, рисуя диаграммы последовательности сообщений или гистограммы использования памяти и т.д. Мне нравится рассматривать только элементы трассировки определенного типа (все прерывания или исключения), или для данного файла или подсистемы и т.д.

Приятный GUI был бы приветствован, как и возможность перейти к строке файла трассировки, соответствующей сообщению на диаграмме последовательности сообщений, или даже к строке исходного кода, соответствующей строке файла трассировки. GUI должен позволять легко включать/исключать типы трассировки, подсистемы и т.д. (например, покажите мне только отправку сообщений и распределение памяти для подсистем F и T).

Кратко говоря, чем больше функций, тем лучше, если они не препятствуют гибкости.

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

Отличный фонд Apache имеет семейство логгеров, которые могут выводить данные на несколько целей.

Из описания варианта Cxx:

Apache log4cxx – это фреймворк для ведения журналов на C++, созданный по образцу Apache log4j, который использует Apache Portable Runtime для большей части платформенно-специфичного кода и должен быть совместим с любой платформой, поддерживаемой APR. Apache log4cxx лицензирован под лицензией Apache, лицензией открытого программного обеспечения, сертифицированной Open Source Initiative.

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

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

В терминах log4cxx, выходное назначение называется аппендером. В настоящее время аппендеры существуют для консоли, файлов, графических компонентов, удаленных сокет-серверов, NT Event Loggers и удаленных демон-систем UNIX Syslog. Также возможно асинхронное ведение журналов.

Для моих нужд есть:

• log4CXX
• log4PHP
• log4c

Полный список можно увидеть здесь

• chainsaw для отображения журналируемых данных, смотрите изображение ниже

Я также ищу решение для ESP 32.

Поскольку большинство языков способны взаимодействовать с C (и/или C++), я, вероятно, возьму либо “официальную” версию Apache CXX (пока неясно, поддерживает ли она C, но не похоже на это), либо более низкоуровневую версию C (минус – это форк) и добавлю обертки, позволяющие вызывать ее, например, из Ada.

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