Что это простыми словами
GDB — это инструмент, который позволяет остановить работающую программу в любой момент и посмотреть, что внутри неё происходит.
Аналогия: представьте, что вы режиссёр, и спектакль вдруг пошёл не по сценарию. GDB — это пульт, которым вы ставите спектакль на паузу, смотрите, кто стоит не там, что держит в руках, и что говорит суфлёр. Разобравшись, вы жмёте «продолжить» — и исправляете ошибку.
В разработке такую процедуру называют «отладкой» (debugging). GDB расшифровывается как GNU Debugger — отладчик из семейства бесплатных инструментов GNU.
Официальное определение
Теперь, когда суть понятна, вот как GDB описывают в вакансиях и документации. Эту формулировку вы встретите в требованиях к системным и embedded-разработчикам.
«GDB (GNU Debugger) — переносимый отладчик с открытым исходным кодом, поддерживающий пошаговое выполнение, точки останова, инспекцию стека вызовов и анализ дампов памяти для программ на C, C++, Assembly и ряде других языков».
Разберём по словам. «Переносимый» — работает на разных операционных системах и процессорах. «Открытый исходный код» — бесплатный, можно установить без лицензии. «Точки останова» — метки, на которых программа сама ставится на паузу, как закладка в книге. «Стек вызовов» — список функций, которые программа выполняла до момента остановки: как история переходов по страницам. «Дамп памяти» — снимок состояния программы в момент сбоя, по которому можно разобраться, что пошло не так.
Какую задачу решает
Программы иногда работают не так, как задумано: зависают, падают, выдают неправильный результат. Чтобы найти причину, разработчику нужно заглянуть «внутрь» работающей программы. GDB даёт именно это.
Конкретные задачи, которые он решает:
Остановить программу в нужном месте и посмотреть, какие значения хранятся в переменных в этот момент.
Пройти код шаг за шагом и увидеть, в какой именно строке логика ломается.
Разобрать аварийный сбой по «снимку» памяти, даже если программа уже не запущена.
Отлаживать программы, работающие на другом устройстве — например, на микроконтроллере или встроенном чипе, к которому подключаются по кабелю.
Последнее особенно важно в embedded-разработке (разработке встроенных систем — программ для микросхем, роботов, промышленного оборудования), где у устройства нет экрана и обычного интерфейса.
Кто им пользуется
GDB не привязан к одному языку или направлению. Им пользуются несколько ролей:
Embedded-разработчик — основной пользователь. Пишет программы для микроконтроллеров и встроенных устройств; GDB помогает отлаживать код прямо на железе.
Системный разработчик (C/C++) — пишет низкоуровневый код: операционные системы, драйверы, сетевые сервисы. GDB — его повседневный инструмент.
Разработчик на Rust или Go — реже, но GDB поддерживает и эти языки; в системных проектах он встречается.
Специалист по информационной безопасности — использует GDB при реверс-инжиниринге (разборе чужого кода) и поиске уязвимостей.
Если в вакансии указан GDB, скорее всего перед вами позиция, связанная с C/C++ или embedded. Это важный ориентир: увидели GDB в резюме — кандидат работал с низкоуровневым кодом.
Аналоги / чем заменяется
GDB — не единственный отладчик. Вот с чем его сравнивают:
LLDB — аналог от Apple, встроен в Xcode (среда разработки на macOS). Умеет то же самое; используется преимущественно на Mac и в iOS-разработке.
WinDbg — отладчик Microsoft для Windows. Применяется при разработке под Windows и анализе системных сбоев.
Встроенные отладчики IDE — Visual Studio, CLion и другие среды разработки имеют графический отладчик «под капотом» которого нередко тот же GDB или LLDB, просто с удобным интерфейсом.
OpenOCD — не прямой аналог, но часто используется вместе с GDB в embedded: служит «мостом» между GDB и физическим устройством.
Переход между отладчиками не очень сложный: концепция одна — точки останова, шаговое выполнение, просмотр памяти. Команды чуть отличаются, но разработчик с опытом GDB освоит LLDB за несколько дней.
Что не путать
GDB ≠ компилятор. Компилятор (например, GCC) превращает написанный код в программу. GDB запускается уже после: он изучает готовую программу в работе. Это два разных инструмента, хотя оба входят в семейство GNU.
GDB ≠ профилировщик. Профилировщик измеряет, что работает медленно. GDB ищет, почему программа ведёт себя неправильно. Цели разные.
GDB ≠ тестовый фреймворк. Тесты проверяют, что функция возвращает правильный результат. GDB нужен, когда тест провалился и нужно понять почему — он инструмент расследования, а не проверки.
«Знает GDB» ≠ «умеет программировать». GDB — один из инструментов разработчика, а не основной навык. Его упоминание в резюме говорит об опыте с низкоуровневым кодом, но не заменяет знание языка.
Насколько это важно при отборе
Короткий ответ: GDB в резюме — сигнал специальности, а не повод для жёсткого фильтра.
Когда GDB — жёсткое требование: позиции embedded-разработчика и системного программиста на C/C++, особенно если работа связана с отладкой прошивок (программ для микросхем) или разработкой для Linux без графической среды. Здесь без GDB или аналога работать буквально невозможно — других инструментов под рукой нет.
Когда требовать именно GDB бессмысленно: если кандидат работал с LLDB или отлаживал код через IDE — он понимает отладку и освоит GDB за несколько дней. Отсеивать человека с опытом C++ и LLDB в пользу кандидата с опытом GDB, но слабее в языке — ошибка.
Если видите GDB в резюме вместе с C, C++ или названиями микроконтроллеров (STM32, ESP32, ARM) — перед вами, скорее всего, embedded- или системный разработчик. Это важный контекст при оценке профиля.
Это общий ориентир. В разных компаниях требования отличаются, поэтому всегда сверяйтесь с текстом конкретной вакансии.