Настройка отладки C++ проекта через GDB в VSCode
Если вы работаете над собственными библиотеками на C++, особенно такими, где важна строгая типизация и предсказуемое поведение компилятора, то наверняка сталкивались с ситуацией, когда Microsoft Visual Studio (MSVS) сама "подчищает" за вами типы или подключает лишние зависимости. Иногда это удобно, но при разработке низкоуровневого кода это может мешать.
В этой статье я расскажу, как перейти с MSVC на MinGW, правильно настроить CMake и использовать GDB для отладки вашего C++-проекта прямо в Visual Studio Code.
Почему стоит выбрать MinGW?
Раньше я использовал MSVC, потому что он шёл "из коробки" с Windows и Visual Studio. Но со временем понял, что он слишком много делает за меня: автоматически приводит типы, подключает стандартные библиотеки, иногда даже не даёт увидеть настоящее поведение программы.
После этого решил попробовать MinGW — порт GCC для Windows. Он оказался отличной заменой:
Работает по принципам GNU Toolchain;
Позволяет писать кроссплатформенный код;
Не лезет в код сам — всё остаётся под вашим контролем;
Поддерживает GDB — мощный отладчик, который можно использовать внутри VSCode.
Именно возможность использовать GDB стала ключевым фактором при переходе с MSVC на MinGW во время разработки своей библиотеки ModernStringС++ ( Github ).
Шаг 1: Настройка CMake под MinGW
До этого я собирал проект так:
cd build
cmake ..
cmake --build . --config ReleaseЭто работало, но всегда использовалось окружение (компилятор) MSVC. Чтобы перейти на MinGW, нужно немного изменить команду:
cmake -B build -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Debug
cmake --build . --config DebugЧто здесь происходит:
-B buildуказывает, что файлы сборки будут генерироваться в директорииbuild;-G "MinGW Makefiles"говорит CMake, что мы хотим использовать именно MinGW;-DCMAKE_BUILD_TYPE=Debugвключает режим отладки, чтобы GDB мог нормально работать.
Если вы хотите собрать релизную версию, просто замените
DebugнаRelease.
Шаг 2: Сборка проекта
После того как CMake сгенерировал нужные файлы, можно запускать сборку:
cmake --build build --config DebugЕсли вы используете Release-сборку, не забудьте указать его явно:
cmake --build build --config ReleaseШаг 3: Включаем GDB в VSCode
Теперь, когда проект собран с флагами отладки, пора подключить GDB. Для этого мне потребовались:
Установленный MinGW-w64 (или MSYS2);
GDB, который идёт в составе MinGW;
Расширение C/C++ в Visual Studio Code.
Конфигурация .vscode/launch.json
Добавьте в свой launch.json следующий блок:
{
"name": "(gdb) Запустить",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/build/ModernString.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}/build",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "C:/msys64/mingw64/bin/gdb.exe" // Путь до дебагерра
}
⚠️ Обязательно проверьте путь к
gdb.exe. У вас он может быть другим, в зависимости от установленного дистрибутива. Ищите через win + S (Не всегда помогает). Я лично использую программу Everything
Эта конфигурация:
Использует GDB как движок отладки;
Запускает программу из папки
build;Не открывает внешний терминал (всё работает внутри VSCode);
Показывает значения переменных, точки останова, стек вызовов и прочие полезности.
Что получается в результате?
После всех этих шагов вы получаете комфортную среду разработки:
Полный контроль над процессом компиляции;
Возможность полноценной отладки через GDB;
Современные возможности C++;
Чистую структуру проекта благодаря CMake.
Несколько советов на заметку
-
Чтобы убедиться, что GDB установлен, просто выполните в терминале:
gdb --version Проверьте, добавлен ли
mingw32-makeв системные переменные окружения PATH.Если возникают ошибки при сборке — сравните версии CMake и MinGW, они должны быть совместимыми.
Для автоматизации сборки и запуска можно использовать файл
tasks.jsonв папке.vscode.
Где почитать больше
Заключение
Переход с MSVC на MinGW дал мне больше контроля над проектом и позволил использовать GDB — один из самых мощных отладчиков для C++. Это особенно важно, если вы пишете свои библиотеки и хотите точно знать, что и как происходит в вашем коде.
Если эта статья вам помогла — ставьте лайк и подписывайтесь на мой канал.
Вопросы, предложения, или просто слова поддержки — пишите в комментариях!
Комментарии (28)
vladz
16.06.2025 14:33Статья выглядит немного однобоко — перечислены некоторые плюсы MinGW (в основном акцент на получении "контроля"), но минусы такого выбора под Windows вовсе не упомянуты.
AndronNSK
16.06.2025 14:33Извините, конечно.
Но отладчик в MS VS как-то на голову выше GDB.
Позволяет писать кроссплатформенный код;
Так то можно писать портируемый код и компилируя на ms vc компилятором. Для кроссплатфооменности есть cmake.
Не лезет в код сам — всё остаётся под вашим контролем;
Остаётся только гадать, что имеет ввиду автор. Странное заявление.
Apoheliy
16.06.2025 14:33Не лезет в код сам
Подозреваю, что автор подразумевал следующее:
В коде для MSVS можно указывать меньше инклюдов и код отлично компилируется (и да, такое есть). Потом код переносится, условно, под Linux+Gcc и при компиляции получаем ворох ошибок, что что-то недообъявлено.
НО, тут могу автора разочаровать: такое есть и в gcc. Причём даже в пределах Linux-ов. В моём случае: код написан под линукс, компилируется без предупреждений; код компилирует другой человек под линуксом (дистрибутив другой и версия компилятора другая) - появляются ошибки, что не хватает инклюдов (в моём случае: #include <string>); добавляю в исходники требуемый инклюд и всё компилируется на отлично: и у меня и у него.
Поэтому хочешь кроссплатформенный код: выбираешь поддерживаемые платформы (с версиями), выбираешь поддерживаемые компиляторы (с версиями) и на этом всём тупо-глупо гоняешь сборку: либо через билдовые машины (если есть), либо вручную скриптиком. Как-то так.
vladz
16.06.2025 14:33Давно было дело, я добавлял в includ-ы filesystem и mingw переставал собирать проект. Пробовал собирать другими (msvc, gcc, clang) - нет проблем. Переход на mingw мне видится поиском приключений (ой, извините) "контроля".
maisvendoo
16.06.2025 14:33Давно было дело, я добавлял в includ-ы filesystem и mingw переставал собирать проект
filesystem? Это тот что появился в C++17? Видимо дело было очень давно, так как mingw поддерживает C++17 начиная с 11-й версии. 13-я же частично поддерживает C++20. Что же касается C++20, то какой компилятор вообще поддерживает полную спецификацию этого стандарта?
martein
16.06.2025 14:33Не могли бы меня ткнуть носом на материалы, в которых описывается создание билдовой машины под все компиляторы? Очень хочу уметь делать такую магию. Заранее благодарен.
Apoheliy
16.06.2025 14:33Если вопрос - это сарказм, то извините не распознал.
И да, не "билдовой машины", а "билдовых машин" (хоть бы и виртуальных).
Итак:
---
Например, если важен локальный контур, можно сделать:
gitlab - основной сервер; там же хранить репозитории; можно и собранные билды туда скидывать (если не хочется отдельный сервер);
билд-машина Debian + gitlab_runner;
...
билд-машина Windows + gitlab_runner.
Повторюсь, всё это обычно запускается на виртуальных машинах. Соответственно, сколько билд-машин запустите - столько и будет компиляторов/операционных систем/окружений. Очевидно, что каждая билдовая машина - это и ресурсы, и настройка, и обновление - в общем лучше это не раздувать. И работать эти виртуалки должны одновременно. Пытаться же на одной машине всё это совместить - может быть тяжеловато (например, у нас не зашло).
---
Если локальный контур не обязателен, то можно часть из серверов (или все) вытащить в облако. Или поискать интернет-хранилища кода со сборкой (в том числе и внешней).
---
Если у вас хоббийный проект (можно так предположить), то можно сделать всё проще (для хобби сам так делаю): либо единая система сборки (например, cmake), либо насоздавать сборочных скриптов под все варианты и в самом репозитории и хранить. Далее перед релизом (т.е. не каждый чекин/коммит) прогоняем через все виртуалки и проверяем на собираемость - просто, доступно, функционально. И через виртуалки гоняем по-очереди, не одновременно.
AndronNSK
16.06.2025 14:33Да, про меньше инклюдов - такое есть.
Но это разработчик сам себе Буратино, если пишет обращения без прописывания инклюдов.
Ещё есть разная работа линкеров в GCC и ms Vc. То, что линкуется ms vc, вообще не факт, что слинкуется GCC.
Но это тоже нужно рулить на уровне cmake.
maisvendoo
16.06.2025 14:33Извините, конечно.
Но отладчик в MS VS как-то на голову выше GDB
Извините, конечно, но, не могли бы вы перечислить, в чем конкретно отладчик из MSVS на голову выше GDB?
maisvendoo
16.06.2025 14:33Накинулись...
А между тем, возможно в силу неопытности, автор не совсем корректно выражает свою мысль. Рискну сделать это за него.
Речь идет, видимо, не конкретно о компиляторе msvs, а всей экосистеме разработки майкрософт под Windows. Не спорю - Visual Studio достаточно удобная вещь, но:Она навязывает использование прекомпиленных хэдеров даже в hello world (привет, stdafx.h, или как там тебя...), при этом явно в этом не сознается.
Она навязывает компилятор со специфичными настройками, так что шаг с проектом на MSVS в сторону другой платформы - боль
Она скрывает от разработчика настройки проекта в явном виде, они доступны только через менюшки и окошки IDE. Уважаемые поклонники майкрософта - вы видели файлы .sln и .vcproject изнутри? Эти демонические xml-портянки? В которых и настройки IDE, и настройки сборки и всё на свете. С которыми невозможно работать с git в текстовом виде, а надо писать километровые .gitignore и .gitattributes чтобы сделать эти файлы бинарными для системы контроля версий, иначе при нажатии любой галочки в менюшке мы получаем красный git status на несколько экранов, я уже молчу про конфликты слияния.... Хотя в нормальном мире кроссплатформенной разработки один CMakeLists.txt решает все задачи в 90% случаев
Она генерирует ураган мусора в каталоге проекта, так что надо писать километровые .gitignore и .gitattributes чтобы это дерьмо не индексировалось в репозитории.
Она навязывает использование своих псевдонимов для тривиальных типов
Можно дальше перечислять, общий вывод один - экосистема разработки майкрософт для C++ намеренно спроектирована с целью прибить разработчика гвоздями и к экосистеме и платформе Windows для которой она разработана. И тем более преступно использование её для обучения, что практикуется у нас повсеместно.
Из недостатков mingw могу отметить толькоМедленная скорость компиляции, в сравнении со своим собратом из мире *nix
Отставание в части поддержки современных стандартов С++, в сравнении со своим собрата из мира *nix
Многие SDK, тот же LunarG Vulkan SDK до недавнего времени не позволяли собирать проекты их использующие компилятором mingw. Тоже касается, например и Steam VR, для использования mingw Там нужен финт ушами.
Многие open source проекты не поддерживают компиляцию этим компилятором для Windows, требуют Visual Studio, хотя почему-то нормально собираются gcc под линуксом. Например QtWebEngine отсутствует в варианте Qt для mingw.
Использование mingw дает некоторую боль, однако, что с моей точки зрения важно конкретно для проектов которыми занимаюсь я - обеспечивает единообразие настроек проекта для Windows и Linux. И вот конкретно я готов жрать этот кактус только ради того чтобы не связываться с экосистемой майкрософт
vladz
16.06.2025 14:33В первом списке приводятся минусы IDE (Visual Studio), во втором списке минусы компилятора (mingw).
Первый список минусов решается переходом на любой текстовый редактор + систему сборки (к примеру cmake). А вот как быть со вторым списком минусов (mingw) ? ни текстовый редактор, ни система сборки их не решат - кактус останется.maisvendoo
16.06.2025 14:33Первый список минусов решается переходом на любой текстовый редактор + систему сборки (к примеру cmake)
Имеет место либо троллинг, либо не знание CMake, затрудняюсь с выбором. Но всё же поясню.
CMake это не система сборки в буквальном смысле, это фронтэнд для нескольких систем сборки, который, по написанному разработчиком скрипту генерирует для этих систем сборки их сценарии. Например MinGW Makefiles для mingw. Что же она генерирует для MSVC? Правильно, солюшн (*.sln), чтобы использовать который необходим... Visual Studio!
Ну ок, допустим есть MSBuild (который правда непонятно как использовать без VS). Как его получить, а также тот самый компилятор "без недостатков"? Правильно, надо устанавливать Visual Studio! Потому как отдельно от IDE тулчейн MS не поставляется. И ладно бы в процессе установки я получал бы C++ тулчейн и IDE. Мне навяливают, без возможности отказаться тулчейн для C#.
То есть выходит, что мы сколько угодно любых редакторов можем использовать, можем использовать CMake, однако вынуждены держать не нужную нам Visaul Studio.кактус останется
Кактус - не компилятор. Кактус - во многом искусственно созданные проблемы с его использованием, прямо вытекающие из монополии MS. Проблемы, в большинстве своем преодолимые.
Замечу, что современные компилируемые языки типа Rust или Go имеют компилятор, не привязанный к конкретной IDE. С чего бы вдруг?vladz
16.06.2025 14:33Что же она генерирует для MSVC? Правильно, солюшн (*.sln), чтобы использовать который необходим... Visual Studio!
А если указать генератор у cmake, то появляется выбор, что генерить. Например, если не хочется .sln, то выбрать генератором: -G "NMake Makefiles" или -G "Ninja" (будет пошустрее на больших проектах). Ninja можно скачать отдельно и указать в путях, один небольшой бинарь.
Потому как отдельно от IDE тулчейн MS не поставляется. И ладно бы в процессе установки я получал бы C++ тулчейн и IDE. Мне навяливают, без возможности отказаться тулчейн для C#.
Есть Build Tools. Качается отдельно от инсталлятора студии. Если качнуть свежее (Build Tools for Visual Studio 2022), запустить vs_BuildTools.exe и выбрать при установке только "Desktop Development with C++", то в результате будет вот что:
Visual Studio Build Tools 2022
17.14.6 (June 2025)The Visual Studio Build Tools allows you to build native and managed MSBuild-based applications without requiring the Visual Studio IDE. There are options to install the Visual C++ compilers and libraries, MFC, ATL, and C++/CLI support.
При этом C# установлен не будет. Это проверяется в инсталяторе, через список установленых компонентов. Например, на сборочные машины частенько ставят именно Build Tools
Кактус - не компилятор. Кактус - во многом искусственно созданные проблемы
Я обьяснил как без IDE (Visual Studio) обойтись.
Кто искусственно создал проблемы и был ли это тролинг, решайте сами.
maisvendoo
16.06.2025 14:33Visual Studio Build Tools 202217.14.6 (June 2025)
Ок, я юрлицо и хочу разрабатывать проприетарное ПО? Мои действия? Покупать лицензию на Visual Studio, который мне не нужен, а нужен только тулчейн?
vladz
16.06.2025 14:33Мои действия?
Обратиться к юристу. Я бы начал общение с фразы "In non-enterprise organizations, up to five users can use Visual Studio Community. In enterprise organizations (meaning those with >250 PCs or >$1 million US Dollars in annual revenue), no use is permitted beyond the open source, academic research, and classroom learning environment scenarios described above."
maisvendoo
16.06.2025 14:33Вот оно мне надо? Просто не могу понять, ради какого такого фатального преимущества я должен отдать предпочтение инструменту с ограничениями в EULA?
К слову о перечисленных мной недостаткахМедленная скорость компиляции, в сравнении со своим собратом из мире *nix
Касается скорее mingw32-make, если использовать ninja - недостаток исчезает.
обучения в классе
Обучение на компиляторе под одну единственную платформу в 2025 году.... (!) Языку который используется на широчайшем спектре программных и аппаратных платформ?
vladz
16.06.2025 14:33Вот оно мне надо? Просто не могу понять, ради какого такого фатального преимущества я должен отдать предпочтение инструменту с ограничениями в EULA?
Это вам решать/отвечать.
С искусственно созданными проблемами вроде разобрались.
maisvendoo
16.06.2025 14:33Это вам решать/отвечать
То есть
Вы: MSVC лучше чем MinGW
Я: Чем лучше?
Вы: Чем MinGW
)))искусственно созданными проблемами вроде разобрались
Вы не внимательно читали. Искусственно созданная проблема - это засилие MSVC как в корпоративной так и академической среде, порожденное агрессивной политикой создавшей его корпорации, и не подкрепленное коль скоро очевидным конкурентным преимуществом. По крайней мере вы мне ни одного преимущества не назвали
vladz
16.06.2025 14:33Не надо за меня говорить. Я лишь ответил на технические утверждения, которые на поверку оказались ложными.
Остальные лозунги без меня 8)
Ах да, расскажите это все людям, которые пишут драйвера по винду. Упомяните про мощь MinGW, отладчик... 8)))
maisvendoo
16.06.2025 14:33Положим я оказался не прав в части модели распространения MSBuild. Ок, я это признаю.
Однако, выше вы просто высокомерно и не аргументированно натыкали ТС носом заявив этоНо отладчик в MS VS как-то на голову выше GDB.
Но не ответив на это
Извините, конечно, но, не могли бы вы перечислить, в чем конкретно отладчик из MSVS на голову выше GDB?
И я нас настаиваю н аргументированном ответе и на этот вопрос
Просто не могу понять, ради какого такого фатального преимущества я должен отдать предпочтение инструменту с ограничениями в EULA?
Извольте
maisvendoo
16.06.2025 14:33Ок, извините, ошибся маленько
Ах да, расскажите это все людям, которые пишут драйвера по винду. Упомяните про мощь MinGW, отладчик... 8)))
Вы берете узкую область разработки ПО которое и не может и не должно быть переносимым. Это ничего не доказывает
vladz
16.06.2025 14:33Это ничего не доказывает
Это доказывает, что инструмент надо выбирать под задачу. И иногда, альтернатив может и не быть.
Ок, извините, ошибся маленько
На этом и завершим... эту странную беседу
maisvendoo
16.06.2025 14:33. И иногда, альтернатив может и не быть.
В мире вещей, созданных человеческими руками не существует ничего, чему не было бы альтернативы
https://github.com/utoni/mingw-w64-dpp
vladz
16.06.2025 14:33Положим я оказался не прав в части модели распространения MSBuild. Ок, я это признаю.
Я только на это и отвечал 8)))
Просто не могу понять, ради какого такого фатального преимущества я должен отдать предпочтение
Я нигде не говорил про "должен" 8)))
Мне дискуссия начинает напоминать анекдот где... "Мама! Он меня су..ой обозвал"
Kelbon
Необязательно так делать, можно просто взять clang