Отладка C и C++ в Bugsaur¶

Адаптер: codelldb — тот же, что и для Rust.

Автоопределения нет

bugsaur init опознаёт Rust, Go, PHP и Python по их файлам-маркерам. У C и C++ такого маркера нет — Makefile, CMakeLists.txt, просто каталог с файлами .c одинаково правдоподобны и ни один не решает дело, — поэтому определение за них и не берётся.

Больше ничего не отсутствует: адаптер тот же самый, что у Rust, и C с C++ он отлаживает прекрасно. Профиль пишется руками — и фикстуры ниже лежат именно для того, чтобы его оттуда скопировать.

Написать профиль¶

Создайте .bugsaur/config.toml в корне проекта самостоятельно:

version = 1
default = "app"

[profiles.app]
adapter = "codelldb"
program = "build/app"

program — это собранный бинарник, путь относительно корня проекта. Корнем считается каталог, в котором лежит .bugsaur/.

Рабочий пример в этом репозитории¶

Две фикстуры показывают всю обвязку целиком:

Фикстура	Что показывает
`fixtures/c-hello`	программа на C с вложенной структурой и массивами, собирается своим Makefile
`fixtures/cpp-hello`	та же форма на C++, с `std::string` и `std::vector`

В каждой лежит .bugsaur/config.toml из примера выше, дословно. Собрать и запустить: make fixture-c / make gui-c, и то же с -cpp.

Обе закрыты живыми тестами против настоящего CodeLLDB — make live-codelldb-c и make live-codelldb-cpp, — так что утверждение этой страницы проверено, а не принято на веру.

Собирать с отладочной информацией¶

В бинарнике обязана быть отладочная информация, иначе отладчику не с чем работать:

gcc / clangCMake

cc -g -O0 -c -o build/main.o src/main.c
cc -g -O0 -o build/app build/main.o

cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build

-g даёт отладочную информацию, -O0 не даёт оптимизатору переставить код у вас под ногами. С включённой оптимизацией точки останова попадают на неожиданные строки, переменные читаются как «optimized out», а шаги прыгают.

На macOS объектные файлы нужно сохранять

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

В Mach-O DWARF не лежит в исполняемом файле. Компилятор оставляет его в объектных файлах, а в бинарник пишет debug map — абсолютные пути обратно на эти .o. Команда cc -g -O0 -o build/app src/main.c компилирует во временный каталог и удаляет объектник сразу после линковки, поэтому каждый путь в карте ведёт в никуда. Сессия стартует, процесс работает, а переменных и номеров строк нет — и это читается как сломанный отладчик, а не как сломанная сборка.

Раздельная компиляция, как выше, оставляет build/main.o на месте, и карта остаётся живой. CMake так и делает. Чужой бинарник проверяется так — каждый путь отсюда обязан существовать:

dsymutil -s build/app | grep OSO

Linux это не касается: там DWARF попадает прямо в исполняемый файл.

C и C++ Bugsaur за вас не собирает — сначала сборка, потом запуск.

Аргументы, рабочий каталог, окружение¶

[profiles.app]
adapter = "codelldb"
program = "build/app"
args = ["--config", "${root}/configs/dev.yaml", "--verbose"]
cwd = "."
env_file = ".env"
env = { LOG_LEVEL = "debug" }

args — командная строка отлаживаемого процесса. ${root} разворачивается в абсолютный путь корня проекта.
cwd — рабочий каталог. Без него берётся корень проекта, а не каталог бинарника.
Сначала env_file, затем env, и env выигрывает. Названный, но отсутствующий env_file — ошибка запуска, а не молчаливый пропуск.

Подробности: Настройка → Аргументы и Переменные окружения.

Подключиться к работающему процессу¶

[profiles.attach]
adapter = "codelldb"
program = "build/app"
mode = "attach"

[profiles.attach.launch_arguments]
pid = 4242

В режиме attach ничего не собирается и не запускается — процесс уже работает. См. Рецепты → Подключение к процессу.

Core dump и своя настройка LLDB¶

Всё, что CodeLLDB принимает, но чему нет поля в схеме профиля, передаётся через launch_arguments — оно уходит адаптеру как есть:

[profiles.core]
adapter = "codelldb"
program = "build/app"

[profiles.core.launch_arguments]
coreDumpPath = "${root}/crash.core"

Это аварийный выход, и он перебивает всё, что Bugsaur сгенерировал для этого ключа. См. Настройка → Справочник.

Диагностика¶

Симптом	Вероятная причина	Куда смотреть
`program is not readable`	бинарник не собран или `program` указывает не туда	сверьте путь с результатом сборки
Сессия не стартует	`codelldb` не виден через `PATH`	Адаптер не запускается
Переменные показывают «optimized out»	собрано с оптимизацией	пересоберите с `-g -O0`
На macOS нет ни переменных, ни номеров строк вообще	собрано и слинковано одной командой, debug map ссылается на удалённые объектники	`dsymutil -s <бинарник> \\| grep OSO`; сначала компиляция в `.o`
Точка останова никак не привязывается	строка неисполняемая или вырезана оптимизатором	Точки останова не срабатывают
В стеке есть фреймы, но нет исходника	исходники переехали после сборки или собирались в контейнере	Исходник не найден