- Съвременната разработка на C/C++ за Linux разчита на GCC, Clang/LLVM и решения като IBM Open XL C/C++, за да предоставя оптимизирани, съвместими със стандартите двоични файлове.
- Ефективното дебъгване в Linux комбинира GDB, IDE интерфейси и правилна DWARF debuginfo, вместо да разчита единствено на интеграции с редактори като VS Code.
- Инструменти като strace, ltrace, SystemTap и работни процеси за core-dump допълват GDB, като разкриват системни повиквания, взаимодействия с библиотеки и състояние след смъртта.
- Последните промени в GDB и RHEL подобряват устойчивостта, скриптирането и безопасността на паметта, което прави мащабното дебъгване на C/C++ по-контролируемо и предвидимо.
Ако сте работили с Windows + Visual Studio и внезапно се окажете в огромна C или C++ кодова база на Linux, промяната може да ви се стори брутална. Преминаването през стотици хиляди редове с GDB зад редактор като VS Code, чакайки 30-60 секунди за всяка стъпка, може да ви накара да се замислите дали правите нещо ужасно погрешно или разработката за Linux е просто бавна по дизайн. Добрата новина е, че съвременните Linux инструменти и дебъгери са изключително способни; трябва само да знаете как да ги настроите и кои инструменти са подходящи за големи C/C++ проекти.
Това ръководство ви превежда през пейзажа на C/C++ компилатори, IDE и инструменти за отстраняване на грешки в Linux, (виж Овладейте Linux от нулата), от GCC, Clang/LLVM и IBM Open XL C/C++ до GDB, Eclipse, SystemTap, strace, ltrace и разширени работни процеси за създаване на дъмп на ядрото. По пътя ще засегнем и класическите настройки за обучение (като Geany + GCC) и ще покажем конкретни съвети за ускоряване на отстраняването на грешки и за това как да направим разработката за Linux с C и C++ много по-близка до комфорта, с който може би сте свикнали в Windows.
Компилатори за C и C++ на Linux: GCC, Clang/LLVM и IBM Open XL
В Linux, референтният инструментариум за C и C++ все още е GCC (GNU Compiler Collection), като g++ е неговият C++ интерфейс. Повечето дистрибуции доставят GCC по подразбиране и почти всички уроци, системи за изграждане и CI конвейери предполагат неговото наличие. Обикновено се компилира с команди като gcc за C и g++ за C++, например g++ -g -O2 main.cpp -o app да се изгради оптимизиран двоичен файл с възможност за отстраняване на грешки.
Clang и екосистемата LLVM са се превърнали в мощна алтернатива на GCC в Linux., предлагайки бърза компилация, отлична диагностика и богат набор от инструменти (статичен анализ, форматиране на код, санитарни инструменти и други). Clang е C/C++ интерфейсът, изграден върху LLVM, модулна инфраструктура за компилатори с отворен код, която поддържа множество архитектури и езици и се поддържа активно от голяма общност.
IBM Open XL C/C++ за Linux на Power е комерсиален набор от инструменти, който тясно интегрира Clang/LLVM с дългогодишния опит на IBM в оптимизацията на компилатори. Насочен към IBM Power системи, той използва съвременните функции на езика C/C++ (включително C++17), стандартните LLVM оптимизации и съвместимостта с GCC, за да предоставя високопроизводителни двоични файлове на Power хардуер. Това означава, че получавате предимствата на екосистемата LLVM плюс платформено настроени оптимизации, разработени от IBM.
За по-стари среди, IBM все още предоставя по-старите XL C/C++ компилатори за Linux., така че организациите със съществуващи вериги за изграждане или ограничения за сертифициране могат да продължат да ги използват, като същевременно постепенно внедряват Open XL C/C++ за по-нови натоварвания.
Класическа обучителна система: GCC и леки IDE
Ако тепърва започвате с C или C++ на Linux, много често срещана и ефективна конфигурация е GCC плюс лека IDE като Geany. Geany е междуплатформен (Linux и Windows), бърз и интегрира основни функции като управление на проекти, команди за изграждане и лесно отстраняване на грешки, без режийните разходи, свързани с пълноценни тежки IDE.
Много дълги курсове по C/C++ за Linux препоръчват точно тази комбинация: GCC като компилатор и Geany като среда за разработка. Чрез такива уроци обикновено изучавате езика от нулата: какво е GNU компилатор и как да го извикате, как да структурирате програма, как да работите с условни изрази, функции, масиви, низове, указатели, структури, обединения, файлов вход/изход и евентуално обектно-ориентирани концепции като наследяване, претоварване на оператори и полиморфизъм в C++.
Въпреки че изборът на IDE варира, основният съвет за инструментариума е последователен: използвайте GCC (или g++) на различни платформи, когато е възможно. В Linux това е настройката по подразбиране; в Windows и macOS можете да инсталирате GCC чрез MinGW, MSYS2, WSL, Homebrew или подобни инструменти, като по този начин поддържате еднакъв работен процес в различните системи и улеснявате споделянето на скриптове и Makefile файлове.
Дори когато IDE абстрахира стъпките за изграждане, разбирането, че просто извиква gcc or g++ зад кулисите е от решаващо значение за отстраняване на грешки в сложни проблеми с изграждането или изпълнението. Опции като -g за информация за грешки, нива на оптимизация като -O0, -O2 or -O3и флагове за настройване на предупреждения или съответствие със стандартите (-Wall, -std=c++17и т.н.) всички са от голямо значение при диагностицирането на фини грешки.
Отстраняване на грешки в големи C++ кодови бази: от VS Code до native GDB
Разработчиците, които преминават от Visual Studio на Windows към Linux, често започват с Visual Studio Code плюс разширение, базирано на GDB, и бързо забелязват, че влизането в дебъгера може да стане болезнено бавно на големи бекенд системи. Не е нечувано да има 30-60 секунди закъснения на всяка стъпка при дебъгване на големи системи за обработка или доставка на документи със стотици хиляди редове и много backend компоненти.
Това бавно преживяване обикновено не е ограничение на самия GDB, а на интеграционния слой или конфигурацията между VS Code и основния дебъгер. Проблеми в разширението за отстраняване на грешки, как се синхронизират точките на прекъсване, как се зарежда информацията за символите и как се превеждат командите на MI (машинния интерфейс) - всичко това може да допринесе за масивни забавяния в сложни реални приложения.
Съобщава се за известни дългогодишни проблеми в разширението VS Code C/C++, свързани с производителността на стъпките с GDB на Linux. За някои екипи това означава, че VS Code е чудесен редактор, но не е непременно най-бързият вариант като фронтенд за дебъгване на огромни C++ услуги; алтернативи като например IDE на Google Antigravity и съществуват оригинални IDE. Когато производителността е критична, много инженери се връщат към директно използване на GDB или преминават към оригинална IDE, по-дълбоко интегрирана с локалната верига от инструменти.
Така че, ако установите, че всяка стъпка във вашата сесия за дебъгване на VS Code в Linux отнема половин минута, не приемайте, че дебъгването в Linux е по своята същност толкова бавно. Преди да се откажете, си струва да тествате GDB директно в терминал върху същия двоичен файл и да сравните поведението. Често, влизането в GDB е драстично по-бързо, което сочи към проблем с конфигурацията или разширението, а не към фундаментален проблем с операционната система или компилатора.
В големите C++ магазини на Linux, популярни алтернативи за удобно дебъгване включват Eclipse с CDT (C/C++ Development Tooling), CLion, Qt Creator, KDevelop и други нативни IDE, които се интегрират по-тясно с GDB и локалната система. Тези среди могат да осигурят навигация в изходния код, прозорци за наблюдение и богати точки на прекъсване, като същевременно използват GDB „под капака“, без натоварването от езиково независими слоеве за отстраняване на грешки.
Информация за отстраняване на грешки в Linux: ELF, DWARF, debuginfo и debugsource
В Linux компилираните програми и споделените библиотеки обикновено се съхраняват в ELF (Executable and Linkable Format) файлове, а свързаната с тях информация за отстраняване на грешки е кодирана във формат DWARF. DWARF съдържа метаданните, от които дебъгерите се нуждаят, за да съпоставят машинния код обратно с изходните файлове, номерата на редовете, функциите, типовете и променливите.
Можете да инспектирате секциите DWARF в двоичен файл ELF с инструменти като readelf -w file, което извлича суровите записи за отстраняване на грешки. Въпреки че обикновено не четете DWARF ръчно, това потвърждава дали е налична информация за отстраняване на грешки и може да бъде безценно за диагностициране на проблеми от типа „няма заредени символи“ в GDB или други инструменти.
Все още съществува по-стар формат за дебъгване, наречен STABS, но се счита за остарял и не се препоръчва за съвременни Linux дистрибуции, като например Red Hat Enterprise Linux. GCC и GDB предоставят максимална поддръжка за STABS, но ключови инструменти в екосистемата (например Valgrind или elfutils) може да не работят правилно с тях, поради което DWARF е силно препоръчителен.
Тъй като данните за дебъгване обикновено са големи, повечето дистрибуции ги разделят от основните двоични файлове в отделни пакети debuginfo и debugsource. Изпълнимият файл, който инсталирате от хранилището по подразбиране, обикновено е лишен от символите си за дебъгване, за да се спести дисково пространство и да се намали заеманата памет, докато съответният пакет debuginfo съдържа данните DWARF и, по избор, debugsource включва съответстващите източници.
В RHEL и подобни системи, изрично изисквате информация за дебъгване по време на компилация, използвайки -g когато изграждате свои собствени проекти с GCC. За системни и библиотеки на трети страни, инсталирани от пакети, можете да получите съответните debuginfo намлява debugsource пакети от специализирани хранилища за дебъгване, често подсказвани директно от GDB, когато забележи липсващи символи по време на сесия за дебъгване.
Инсталиране и намиране на debuginfo за системни двоични файлове
Когато отстранявате грешки в C или C++ програми, които зависят от системни библиотеки, инсталирането на debuginfo за тези библиотеки може да окаже огромно влияние върху качеството на обратните проследявания и проверката на променливите. Без него виждате само сурови адреси или объркани имена на функции в споделените библиотеки; с него получавате прецизни до един ред стекови трасирания и символични имена на променливи.
В RHEL-подобни дистрибуции, GNU Debugger (GDB) може автоматично да открие кога липсва информация за отстраняване на грешки за зареден обект и да предложи конкретна команда за инсталиране на необходимата. debuginfo пакет чрез dnf. Просто изпълнявате препоръчаното dnf debuginfo-install ... команда, потвърдете, когато бъдете подканени, и системата извлича и инсталира пакетите със символи, необходими за вашата сесия.
Ако автоматичните подсказки не са налични, можете ръчно да идентифицирате необходимата информация за отстраняване на грешки, като намерите двоичния или библиотечния файл с инструменти като locate и след това запитване към RPM базата данни. - locate командата идва от mlocate пакет, който може да се наложи да инсталирате и инициализирате, и след като имате пътя, можете да попитате кой пакет го притежава и след това да инсталирате съответния вариант на debuginfo.
Има ситуации, в които пакетът, който е инсталирал даден двоичен файл, не може да бъде определен, например когато файлът е копиран ръчно или е изграден на място без пакетиране. В тези случаи може да се наложи да се върнете към персонализирани файлове със символи или, ако е възможно, да пресъздадете двоичния файл сами с -g активирано, така че GDB да има пълни данни за отстраняване на грешки.
Не забравяйте, че инсталирането на debuginfo за всяка отделна библиотека в системата рядко е необходимо и може да бъде разточително. Фокусирайте се върху модулите, които са най-подходящи за вашия проблем: двоичните файлове на вашето приложение и специфичните библиотеки, от които произлиза сривът или неправилното поведение, вместо да изтегляте пакети за отстраняване на грешки за цялата операционна система.
Използване на GDB за интерактивно отстраняване на грешки в Linux
GDB е централният инструмент за дебъгване на оригинални C и C++ приложения в Linux, предоставяйки както интерфейс от команден ред, така и, чрез интеграции, графични интерфейси като Eclipse CDT. В Red Hat Enterprise Linux стандартната дистрибуция включва пълнофункционалния GDB, заедно с опционални графични потребителски интерфейси.
За да отстраните грешки в програма от самото начало, обикновено извиквате gdb ./program, конфигурирайте точките на прекъсване, ако е необходимо, след което стартирайте изпълнението в GDB с run команда. Като алтернатива, можете да се прикачите към програма, която вече работи с gdb -p <pid> или чрез стартиране на GDB и използване на attach командата заедно с идентификатора на процеса.
Ако GDB не може да определи целевия изпълним файл за даден PID по време на прикачване, можете изрично да му кажете кой двоичен файл да използва чрез file команда и след това продължете с дебъгването. Това е особено полезно, когато работите с персонализирани стартери, обвиващи скриптове или многобинарни конфигурации, където действителният път до изпълнимия файл не е очевиден.
След като се прикачите или стартирате, вие контролирате потока на програмата с команди като n (следващ), s (стъпка), until, finish и просто c (продължи), докато излизате от дебъгера с q когато е направено. Всяка от тези команди има специфична семантика относно това дали преминава в телата на функциите, изпълнява се до даден ред или възобновява изпълнението до следващата точка на прекъсване или прекратяване.
За разбиране на състоянието, GDB предоставя богати команди за интроспекция, за да проверява променливи, стекове от повиквания, регистри и други, а също така предлага контекстуална помощ чрез help info и подобни команди. Можете да покажете текущия ред с изходния код с list, отпечатайте променливи с print, изследвайте стековите рамки с backtrace и да навигирате по кадрите с frame, up намлява down.
Точки на прекъсване, точки на наблюдение и условия в GDB
В реалния свят при дебъгване почти никога не се отстъпва сляпо от main(); вместо това, стратегически поставяте точки на прекъсване, за да спрете програмата точно там, където поведението става интересно. Стандартната команда break позволява ви да задавате точки на прекъсване или по номер на файл и ред, или по име на функция, а GDB ще паузира изпълнението при следващото попадение.
Например, можете да зададете точка на прекъсване на конкретен ред от изходния код, използвайки синтаксис като break file.cpp:123или прекъсване в началото на функция с break my_function. Когато се достигне точката на прекъсване, GDB спира програмата, позволявайки ви да инспектирате локалните променливи, да проверите стека от извиквания и да решите дали да се включите, да преминете през стъпка 1 или да продължите.
Условните точки на прекъсване са безценни, когато дадена грешка се появява само след много итерации или при определени входни стойности. Можете да свържете булево условие, написано на C или C++, с точка на прекъсване, така че GDB да спира само когато условието се оцени като true, което драстично намалява ненужните спирания и прави циклите за отстраняване на грешки или сложните машини на състоянията много по-ефективни.
За да наблюдава промените в данните, а не потока на кода, GDB предлага точки за наблюдение, които се задействат, когато израз (често променлива) се чете или записва в него. С команди като watch, rwatch (прочетете) или awatch (четене/запис), можете да спрете изпълнението точно когато определено поле бъде променено или достъпно, което е особено полезно при проследяване на неочаквани промени в състоянието.
Вие управлявате всички точки на прекъсване и точки на наблюдение чрез команди като info breakpoints or info brи можете да изтривате по номер или по местоположение, като използвате delete с подходящи аргументи. Това улеснява поддържането на чист набор от активни точки на прекъсване и предотвратява объркване при дебъгване в множество модули или сесии.
Отстраняване на грешки в многонишкови и разклонени процеси
Отстраняването на грешки в C и C++ програми, които използват интензивно нишки или разклонения, изисква допълнителна представа за това как GDB проследява контекстите на изпълнение. По подразбиране GDB обозначава текуща нишка и повечето команди работят с тази нишка, освен ако изрично не превключите, използвайки thread и идентификаторът на нишката.
Когато програмата ви се разклонява, настройката set detach-on-fork определя дали GDB следва детето или родителя и как обработва неследения процес. Можете да конфигурирате GDB или да контролира и двете, или да се отделя автоматично от едната страна, в зависимост от това дали родителят, детето или и двете са релевантни за вашия анализ.
По-новите версии на GDB са развили начина, по който се номерират нишките, въвеждайки идентификатор за всяка по-нисша нишка, заедно с отделен глобален идентификатор на нишката за съвместимост. Променливата на удобството $_thread и Python API-тата InferiorThread.num сега отразяват номерирането за всеки по-нисък елемент, докато глобалният идентификатор е достъпен чрез $_gthread намлява InferiorThread.global_num, като по този начин се гарантира, че по-старите инструменти, базирани на глобални идентификатори, продължават да работят.
Обработката на сигнали при многонишково дебъгване също е подобрена, така че сигналите винаги да се доставят до правилната нишка. Ако промените нишката, след като сигнал спре програмата и след това се опитате да продължите, GDB може да поиска потвърждение, предотвратявайки случайно неправилно доставяне и правейки отстраняването на грешки, свързано със сигнала, по-надеждно.
Всичко това означава, че когато анализирате блокирания, състезания или странни сривове, задействани от сигнали, можете да разчитате на модела на нишките на GDB, за да проследите правилния път на изпълнение с прецизен контрол. В комбинация с точки на прекъсване, точки на наблюдение и точки на улов, това позволява стабилно многонишково дебъгване дори в C++ услуги с висока степен на едновременна работа.
Система за проследяване и библиотечни извиквания: strace, ltrace и SystemTap
Понякога най-бързият начин да разберете защо една C или C++ програма се държи неправилно не е да прегледате всеки ред, а да наблюдавате как тя взаимодейства с операционната система и нейните споделени библиотеки. Linux предлага няколко мощни инструмента за това: strace, ltrace, SystemTap и дори самият GDB чрез специализирани catchpoints.
- strace помощната програма проследява системните повиквания – взаимодействия с ядрото, като например open, read, write, mmap, execve и така нататък – заедно с техните параметри и връщани стойности. Можете да стартирате програмата си чрез strace или да се прикачи към работещ процес чрез PID, като по избор се филтрира кои системни извиквания да се показват, използвайки изрази като -e trace=call и контролиране дали да се следват разклонени или нишковидни деца с -f.
Тъй като реалните приложения издават огромен брой системни извиквания, комбинирайки strace с инструменти за обвивка като tee е обичайно както да се преглежда резултатът на живо, така и да се съхранява за анализ. Това ви помага да идентифицирате липсващи файлове, проблеми с разрешенията, неочаквано мрежово поведение или други проблеми на ниво операционна система, които може да не са очевидни от самия код.
Допълване на страце, ltrace фокусира се върху извикванията на функции на споделени библиотеки в потребителското пространство, показвайки извиквания и връщани стойности за експортирани функции от динамични обекти. В RHEL 8 има известно ограничение, при което ltrace не може да проследява определени системни изпълними файлове, но работи нормално за потребителски изпълними файлове, което го прави ценен инструмент за разбиране как вашата програма използва библиотечни API.
SystemTap е по-усъвършенствана рамка за проследяване, която позволява персонализирани обработчици на събития както за събития в ядрото, така и за събития в потребителското пространство, използвайки собствен скриптов език. Може да е по-сложен за използване от strace или ltrace, но се мащабира по-добре и поддържа сложно филтриране и агрегиране. За удобство, примерен скрипт, наречен strace.stp Доставя се със SystemTap, за да имитира подобно на strace поведение, използвайки инфраструктурата на SystemTap.
Самият GDB може да участва в проследяването, като използва точки за отчитане на системни повиквания и сигнали, чрез команди като catch syscall намлява catch signal. Тези фактори карат дебъгера да спре изпълнението си, когато програмата изпълнява определени системни повиквания или получава конкретни сигнали, което може да бъде много удобно, когато се нуждаете от прецизен контрол по време на интерактивно дебъгване.
Основни дъмпове и отстраняване на грешки след смъртта с GDB
Когато C или C++ приложение се срине или замръзне по начин, който е трудно да се възпроизведе интерактивно, дъмповете на ядрото предоставят моментна снимка на неговата памет и състояние в критичния момент. Дъмпът на ядрото е ELF файл, съдържащ съдържанието на части от паметта на процеса (стек, heap, mappings) при прекратяване, което можете да анализирате по-късно с GDB, сякаш сте били свързани по време на срива.
За да използвате ефективно дъмповете на ядрото, трябва да се уверите, че те действително са генерирани и не са блокирани от ограничения на ресурсите или конфигурация. Ограничения на Shell, като например ulimit -c може да предотврати създаването на основни файлове; задаване на ограничението до unlimited премахва ограниченията на размера, въпреки че трябва да прегледате последиците за дисковото пространство в производствените системи.
В съвременните RHEL системи, systemd-coredump управлява прозрачно дъмповете на ядрото и ги съхранява в централизирано място, подобно на журнал, вместо да ги оставя core файлове, разпръснати по директории. - coredumpctl Инструментът ви позволява да изброите записаните сривове, да проверите техните метаданни и да експортирате действителния основен файл в избран път за по-задълбочен анализ.
При създаването на систематичен работен процес за улавяне на сривове е обичайно да се инсталира sos опаковка и употреба sosreport за генериране на tarball със системна конфигурация и лог файлове. В комбинация с експортирания основен файл и двоичните файлове на приложението, това ви дава всичко необходимо, за да анализирате сривове на отделна машина или да ги предадете на друг екип или доставчик.
Можете дори умишлено да задействате дъмп на ядрото за неотговарящ процес, като му изпратите сигнал за прекъсване или използвате инструменти като gcore, които изхвърлят паметта на процеса, докато той все още се изпълнява. по време на gcore dump, процесът спира за кратко, след което възобновява нормалното си изпълнение, което позволява офлайн анализ на проблемно състояние, без да се прекратява напълно услугата.
Намиране на правилния изпълним файл и символи за анализ на ядрото
За да анализира смислено дъмп на ядрото, GDB се нуждае както от файла на ядрото, така и от точния изпълним файл (плюс всички съответни споделени библиотеки), който го е създал. Това е важно, защото несъответстващите двоични файлове – изградени от различни версии – могат да доведат до подвеждащи обратни следи и неправилно оформление на променливите.
Инструменти като coredumpctl info покажете подробни метаданни за всяко заснето ядро, включително пътя до главния изпълним файл и идентификатор на компилацията, който уникално идентифицира двоичния файл. Идентификаторът на компилацията може да изглежда като дълъг шестнадесетичен хеш и можете да го сравните с идентификатора на компилацията на вашето локално копие на двоичния файл, за да се уверите, че са идентични, преди да стартирате GDB.
Ако изпълнимият файл и неговите библиотеки са от RPM пакети, можете да използвате sosreport и базата данни с пакети, за да извлечете точните необходими версии. В някои случаи можете дори да преинсталирате съответстващите пакети на специална машина за дебъгване и след това да използвате GDB-тата. set sysroot конфигурация, за да го насочи към огледално оформление на библиотеката за отдалечено отстраняване на грешки.
След като имате правилните обекти, стартирате GDB сесия с команда като например gdb /path/to/exe /path/to/core и нека GDB зареди ядрото. Ако липсва debuginfo за някои модули, GDB ще покаже съобщения, подсказващи кои пакети или файлове със символи трябва да инсталирате, за да получите пълна видимост на символите.
Ако символите за отстраняване на грешки на вашето приложение са предоставени в отделни файлове, а не чрез пакети, можете да ги заредите изрично, като използвате symbol-file команда вътре в GDB. Не сте задължени да имате информация за отстраняване на грешки за всяка отделна споделена библиотека в ядрото; фокусирането върху вашето собствено приложение и подозрителните библиотеки обикновено е достатъчно, за да се реконструира съответният стек и състояние.
Когато анализирате дъмп на ядрото, не забравяйте, че командите за управление на изпълнението на програмата (като step или continue) вече нямат смисъл, защото няма прикачен активен процес. Вместо това, разчитате на команди за проверка – разглеждане на стекови рамки, локални и глобални променливи, региони на паметта и нишки – за да заключите защо се е случил сривът или къде програмата е заседнала.
Разширени сценарии за дъмп на паметта и промени в GDB на съвременен RHEL
Някои приложения с висока сигурност или висока производителност маркират части от паметта си като недъмпингови, използвайки флагове като VM_DONTDUMP, което предотвратява записването на тази памет в основните файлове. Това защитава чувствителни данни (например криптографски ключове или финансови записи) и намалява размера на дъмповете, но затруднява пълния офлайн анализ.
Ако имате силна нужда да заснемете всичко – включително области, които обикновено са изключени от дъмповете – можете да конфигурирате GDB да игнорира флага за не-дъмп и да наложи цялостен дъмп на паметта. GDB предоставя опции за отмяна VM_DONTDUMP и да изхвърлите цялата памет на процеса в основен файл за криминалистика или дълбоко дебъгване.
От страна на инструментите, версията на GDB, доставяна с RHEL 8, въвежда редица промени в поведението и прекъсванията в сравнение с RHEL 7, особено в области, където хората са анализирали терминалния му изход. Вместо да се извлича текстов изход, Red Hat препоръчва писане на скриптове, използвайки Python API на GDB или протокола Machine Interface (MI), като и двата са предназначени за програмна консумация.
Забележителните промени включват стартирането на подчинени сървъри от GDBserver чрез shell, за да се позволи разширяване на аргументите, премахване на поддръжката на GCJ (Java), актуализиран синтаксис за командите за извличане на символи за поддръжка и корекции в обработката на sysroot за по-добра поддръжка на отдалечено отстраняване на грешки. Някои команди и режими, като например съвместимост с HP-UX XDB и remotebaud, са били оттеглени или заменени с по-общи еквиваленти като set serial baud.
В допълнение, GDB въведе ограничения като max-value-size За да се предотврати неограничено разпределение на паметта при отпечатване на много големи стойности, е променен начинът, по който се контролира размерът на историята на командите чрез GDBHISTSIZE вместо HISTSIZEи добави ограничение за кандидатите за завършване чрез set max-completions. Тези предпазни мерки помагат да се избегне замръзване или прекомерна консумация на памет при отстраняване на грешки в патологични или повредени програми.
Крайният ефект за C и C++ разработчиците в Linux е по-стабилен, скриптоподобен дебъгер, който се мащабира до огромни кодови бази и странни сценарии на неуспех, стига да сте запознати с актуализираните команди и бутони за конфигуриране. В комбинация със съвременни компилаторни инфраструктури като GCC и Clang/LLVM (и предложения като IBM Open XL C/C++ на Power), GDB формира гръбнака на мощна верига от инструменти за разработване и отстраняване на проблеми със сложен оригинален софтуер на Linux.
Изборът на правилния компилатор и IDE, активирането на DWARF debug info и инсталирането на debuginfo пакети, както и използването на работни процеси GDB, strace, ltrace, SystemTap и core-dump, ви дава Linux C/C++ среда, която е бърза, прозрачна и подходяща за най-големите backend-ове, дори ако първите ви впечатления са дошли от бавна сесия за дебъгване на VS Code. С правилната конфигурация и познаване на наличните инструменти, дебъгването в Linux не само е равно на комфорта на Visual Studio в Windows; в много сценарии то всъщност ви дава по-фин контрол и по-задълбочена видимост върху това как вашите C и C++ приложения действително се държат.
