Blog

📄

Три способа подружить наследование классов и реляционные таблицы

22.04.2026 DataBas
Объектно-ориентированные языки поддерживают наследование классов напрямую. В реляционных базах данных такого встроенного механизма нет. Разработчикам приходится самостоятельно решать, как отобразить иерархию объектов на плоские таблицы. Для…
📄

Домашний инференс — достижимо?

01.04.2026 LLM
В настоящее время использование LLM для генерации кода, как на работе, так и в пет проектах становится нормой. LLM перестают быть простыми игрушками и становятся прекрасным…
📄

Построение модульных проектов на C#: от монолита к гибкой архитектуре

14.02.2026 CSharp
Введение: Почему модульность — не роскошь, а необходимость Модульная архитектура в C# — это не просто модный тренд, а практический подход к созданию масштабируемых, тестируемых и поддерживаемых приложений. Когда…
📄

Кросплатформенные CLI приложения на C#: выбор инструментов, особенности и сравнение с альтернативами

01.02.2026 CSharp
Введение: Почему C# для кросплатформенных CLI? В первую очередь — это из-за минимального порога входа. Ну нужно разбираться в GUI-фреймворках, версткой или мобильных платформах. Можно сразу…
📄

Неблокирующие семафоры в Go: полное руководство со сравнением реализаций

24.11.2025 Golang
В данной статье мы рассмотрим в различные способы реализации неблокирующизх семафоров в Go. Рассмотрим как преимущества той или иной реализации, так и недостатки. Что такое неблокирующий…
📄

Продвинутая сборка: Создание и распространение DEB пакетов для C++/Qt приложения с помощью CPack

04.10.2025 CMake
После того как мы освоили создание пакетов с отладочными символами (dbgsym), логичным продолжением становится изучение сборки основных пакетов для распространения вашего C++/Qt приложения. В этой статье…
📄

Профилирование памяти в С++

04.10.2025 CXX
Проблема стабильности программного обеспечения В процессе разработки и эксплуатации программного обеспечения на языке C++ нередко возникают ситуации, требующие детального анализа производительности приложения. Классическим случаем является аварийное…
📄

Руководство по созданию и установке отладочных символов в DEB пакетах

01.10.2025 dbgsym
Отладочные символы — это критически важный компонент для эффективной отладки программного обеспечения. Они связывают исполняемый код с исходным кодом, позволяя разработчикам видеть имена переменных, функции, строки…

Отладочные символы — это критически важный компонент для эффективной отладки программного обеспечения. Они связывают исполняемый код с исходным кодом, позволяя разработчикам видеть имена переменных, функции, строки исходного кода и структуры данных во время отладки. В этом руководстве мы подробно рассмотрим процесс создания, упаковки и установки отладочных символов для проектов на C/C++ в формате DEB пакетов.

Техническое объяснение

Отладочные символы — это специальная метаинформация, которая сохраняется в бинарных файлах во время компиляции. Они включают:

  • Таблицы символов — соответствие между адресами в памяти и именами функций/переменных
  • Информацию о типах данных — структуры, классы, их члены и методы
  • Сведения об исходном коде — номера строк, имена файлов, пути
  • Информацию о стеке — расположение локальных переменных и параметров функций

Практическая ценность

Без отладочных символов отладчик показывает только:

  • Адреса памяти вместо имен функций
  • Машинные коды вместо строк исходного кода
  • Шестнадцатеричные значения вместо понятных структур данных

С отладочными символами вы получаете:

  • Читаемые имена функций в backtrace
  • Возможность просмотра значений переменных по именам
  • Навигацию по исходному коду во время отладки
  • Понимание структуры сложных объектов

Подготовка проекта

Настройка системы сборки

Чтобы сформировать отдельный deb-пакет с отладочными символами для C++ проекта, собранного через CMake и CPack, достаточно включить соответствующую опцию в CMakeLists.txt и убедиться, что отладочные символы присутствуют в бинарниках — сборка должна быть в режиме «Debug» или «RelWithDebInfo».

Шаги для создания отдельного пакета dbgsym через CPack

  • В корневой CMakeLists.txt добавьте:
set(CPACK_DEBIAN_DEBUGINFO_PACKAGE ON)
set(CMAKE_BUILD_TYPE Debug)

Переменная CPACK_DEBIAN_DEBUGINFO_PACKAGE отвечает за автоматическую генерацию отдельного .ddeb-пакета с отладочными символами.

  • Сборка проекта:
cmake -DCMAKE_BUILD_TYPE=Debug .
make
  • Соберите оба пакета:
cpack -G DEB

В результате появятся основной deb-пакет и дополнительный, содержащий только отладочные символы (обычно с суффиксом «dbgsym»).

Важные нюансы

  • Не используйте опции, которые заранее «strip»-ят бинарники (например, CPACK_STRIP_FILES), иначе дебажные символы будут удалены и dbgsym-пакет не соберётся.
  • Если используются компонентные пакеты, например, несколько библиотек, для каждого компонента можно задать свой debuginfo-пакет через CPACK_DEBIAN_<component>_DEBUGINFO_PACKAGE.
  • Пакет можно установить обычными средствами (dpkg, apt) для последующей отладки — бинарник основной пакет, dbgsym-пакет загружает отладочные символы, что удобно для анализа аварий и профилирования.

Рекомендуется использовать актуальную версию CMake (от 3.13 и выше), так как поддержка dbgsym-пакетов появилась начиная с этого релиза.

Важно

  • Если пакет нужен для релиза, используйте RelWithDebInfo вместо Debug, чтобы были и оптимизации, и дебаг-символы:
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_INSTALL_PREFIX=/usr ..