C и C++ програмски софтвер и алати за дебаговање на Линуксу

Почетна » Питон » C и C++ програмски софтвер и алати за дебаговање на Линуксу

Ако долазите са Windows + Visual Studio позадине и изненада се нађете у огромној C или C++ кодној бази на Linux-у, промена може деловати брутално. Пролазак кроз стотине хиљада редова са GDB-ом иза едитора као што је VS Code, чекајући 30-60 секунди за сваки корак, може вас натерати да се запитате да ли радите нешто ужасно погрешно или је развој за Линукс једноставно спор по дизајну. Добра вест је да су модерни Линукс алати и дебагери изузетно способни; само треба да знате како да их подесите и који алати одговарају великим C/C++ пројектима.

Овај водич вас води кроз свет C/C++ компајлера, IDE-а и алата за отклањање грешака на Линуксу., (видети Савладајте Линукс од нуле), од GCC-а, Clang/LLVM-а и IBM Open XL C/C++ до GDB-а, Eclipse-а, SystemTap-а, strace-а, ltrace-а и напредних токова рада са исписивањем дампа језгра. Успут ћемо се дотаћи и класичних подешавања учења (као што су Geany + GCC) и показати конкретне савете за убрзавање дебаговања и приближавање развоја за Linux помоћу C-а и C++-а удобности на коју сте можда навикли на Windows-у.

Компајлери за C и C++ на Линуксу: GCC, Clang/LLVM и IBM Open XL

На Линуксу, референтни алат за C и C++ је и даље GCC (GNU Compiler Collection), са g++ као његовим C++ фронт-ендом. Већина дистрибуција подразумевано испоручује GCC, и готово сви туторијали, системи за изградњу и CI цевоводи претпостављају његово присуство. Обично се компајлира помоћу команди као што су gcc за Ц и g++ за C++, на пример g++ -g -O2 main.cpp -o app да се направи бинарна датотека која се може отклањати погрешно.

Clang и LLVM екосистем су израсли у моћну алтернативу GCC-у на Линуксу, нудећи брзу компајлацију, одличну дијагностику и богат скуп алата (статичка анализа, форматирање кода, средства за дезинфекцију и још много тога). 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++ на Линуксу, веома уобичајена и ефикасна поставка је GCC плус лагани IDE као што је Geany. Geany је вишеплатформски (Linux и Windows), брз и интегрише основне функције попут управљања пројектима, команди за изградњу и једноставног дебаговања без оптерећења које изазивају тешки IDE-ови.

Многи дугачки C/C++ курсеви за Linux препоручују управо ову комбинацију: GCC као компајлер и Geany као развојно окружење. Кроз такве туторијале, обично учите језик од темеља: шта је ГНУ компајлер и како га позвати, како структурирати програм, како радити са условним изразима, функцијама, низовима, стринговима, показивачима, структурама, унијама, улазно-излазним операцијама датотека и на крају објектно оријентисаним концептима попут наслеђивања, преоптерећења оператора и полиморфизма у C++.

Иако се избори IDE-а разликују, основни савети за алате су обично доследни: користите GCC (или g++) на свим платформама кад год је то могуће. На Линуксу је ово подразумевана поставка; на Виндоусу и МацОС-у можете инсталирати ГЦЦ путем МинГВ, МСИС2, ВСЛ, Хоумбрев или сличних алата, одржавајући јединствен ток рада на свим системима и олакшавајући дељење скрипти и Макефајлова.

Чак и када IDE апстрахује кораке изградње, разумевање да једноставно позива gcc or g++ иза кулиса је кључно за отклањање грешака у сложеним проблемима са изградњом или извршавањем. Опције попут -g за информације о дебаговању, нивои оптимизације као што су -O0, -O2 or -O3и ознаке за подешавање упозорења или усклађености са стандардима (-Wall, -std=c++17итд.) све је веома важно приликом дијагностиковања суптилних грешака.

Отклањање грешака у великим C++ кодним базама: од VS кода до нативног GDB-а

Програмери који прелазе са Visual Studio-а на Windows-у на Linux често почињу са Visual Studio Code-ом плус GDB-базирано проширење и брзо примећују да покретање дебагера може постати болно споро на великим серверским системима. Није нечувено да постоје кашњења од 30-60 секунди на сваком кораку приликом дебаговања великих система за обраду или испоруку докумената са стотинама хиљада линија и многим бекенд компонентама.

Ово споро искуство обично није ограничење самог GDB-а, већ интеграционог слоја или конфигурације између VS Code-а и основног дебагера. Проблеми у проширењу за отклањање грешака, начин синхронизације тачака прекида, начин учитавања информација о симболима и начин превода MI (машинских интерфејса) команди могу допринети масовним успоравању у сложеним апликацијама из стварног света.

Постоје познати дугогодишњи проблеми пријављени у VS Code C/C++ екстензији везани за перформансе корачења са GDB-ом на Linux-у. За неке тимове, ово значи да је VS Code одличан као едитор, али не нужно и најбржа опција као фронт-енд за дебаговање огромних C++ сервиса; алтернативе као што су Google Antigravity IDE и постоје изворни IDE-ови. Када су перформансе критичне, многи инжењери се враћају директном коришћењу GDB-а или прелазе на изворни IDE који је дубље интегрисан са локалним ланцем алата.

Дакле, ако откријете да сваки корак у вашој сесији дебаговања VS Code-а на Линуксу траје пола минута, немојте претпостављати да је дебаговање у Линуксу по својој природи толико споро. Пре него што одустанете, вреди тестирати GDB директно у терминалу на истом бинарном фајлу и упоредити понашање. Често је улазак у GDB драматично бржи, што указује на уско грло конфигурације или проширења, а не на фундаментални проблем ОС-а или компајлера.

У великим C++ продавницама на Линуксу, популарне алтернативе за удобно дебаговање укључују Eclipse са CDT-ом (C/C++ Development Tooling), CLion, Qt Creator, KDevelop и друге изворне IDE-ове који се чвршће интегришу са GDB-ом и локалним системом. Ова окружења могу да обезбеде навигацију кроз изворни код, прозоре за праћење и богате тачке прекида, а да притом користе GDB „испод хаубе“ без оптерећења слојева за отклањање грешака независних од језика.

Информације о отклањању грешака на Линуксу: ELF, DWARF, debuginfo и debugsource

На Линуксу, компајлирани програми и дељене библиотеке се обично чувају у ELF (Executable and Linkable Format) датотекама, а њихове повезане информације за отклањање грешака су кодиране у DWARF формату. DWARF садржи метаподатке који су дебагерима потребни за мапирање машинског кода назад у изворне датотеке, бројеве линија, функције, типове и променљиве.

Можете прегледати DWARF секције у ELF бинарном фајлу помоћу алата као што су readelf -w file, који приказује сирове записе о отклањању грешака. Иако обично не читате DWARF ручно, ово потврђује да ли су присутне информације за дебаговање и може бити непроцењиво за дијагностиковање проблема типа „нема учитаних симбола“ у GDB-у или другим алатима.

Старији формат за дебаговање под називом STABS и даље постоји, али се сматра застарелим и не препоручује се на модерним Линук дистрибуцијама као што је 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-а за интерактивно дебаговање на Линуксу

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 зауставља програм, омогућавајући вам да прегледате локалне променљиве, проверите стек позива и одлучите да ли да пређете на другу локацију, пређете преко друге или наставите.

Условне тачке прекида су непроцењиве када се грешка појави тек након много итерација или под одређеним улазним вредностима. Можете повезати Булов услов написан у C или C++ са тачком прекида тако да GDB зауставља рад само када се услов процени као тачан, драматично смањујући непотребна заустављања и чинећи петље за отклањање грешака или сложене машине стања много ефикаснијим.

Да би пратио промене у подацима, а не ток кода, GDB нуди тачке праћења, које се активирају када се израз (често променљива) чита из њега или уписује у њега. Са командама као што су watch, rwatch (читај) или awatch (читање/писање), можете зауставити извршавање тачно када се одређено поље модификује или му се приступи, што је посебно корисно за праћење неочекиваних промена стања.

Свим тачкама прекида и тачкама праћења управљате помоћу команди као што су info breakpoints or info br, а можете брисати по броју или по локацији користећи delete са одговарајућим аргументима. Ово олакшава одржавање чистог скупа активних тачака прекида и спречава забуну приликом дебаговања у више модула или сесија.

Отклањање грешака у вишенитним и форкованим процесима

Отклањање грешака у C и C++ програмима који интензивно користе нити или форкове захтева додатну свест о томе како GDB прати контексте извршавања. Подразумевано, GDB означава тренутну нит и већина команди ради на тој нити осим ако експлицитно не пребаците користећи thread и идентификатор нити.

Када се ваш програм форкује, подешавање set detach-on-fork одређује да ли GDB прати дете или родитеља и како поступа са процесом који се не прати. Можете конфигурисати GDB да задржи контролу над обе стране или да се аутоматски одвоји од једне стране, у зависности од тога да ли су родитељ, дете или оба релевантна за вашу анализу.

Новије верзије GDB-а су еволуирале начин нумерације нити, уводећи ИД за сваку инфериорну нит заједно са посебним глобалним ИД-ом нити ради компатибилности. Променљива погодности $_thread и Пајтон API-је InferiorThread.num сада одражавају нумерацију по инфериорним вредностима, док је глобални идентификатор доступан преко $_gthread InferiorThread.global_num, осигуравајући да старији алати засновани на глобалним ИД-овима наставе да раде.

Обрада сигнала у вишенитном дебаговању је такође побољшана тако да се сигнали увек испоручују исправној нити. Ако промените нит након што сигнал заустави програм, а затим покушате да наставите, GDB може да затражи потврду, спречавајући случајну погрешну испоруку и чинећи дебаговање повезано са сигналом поузданијим.

Све ово значи да приликом анализе застоја, трка или чудних падова изазваних сигналима, можете се ослонити на GDB-ов модел нити да бисте пратили праву путању извршавања са прецизном контролом. У комбинацији са тачкама прекида, тачкама праћења и тачкама хватања, ово омогућава робусно отклањање грешака у више нити чак и у C++ сервисима са високим бројем конкурентних функција.

Систем праћења и позиви библиотека: strace, ltrace и SystemTap

Понекад најбржи начин да се разуме зашто се C или C++ програм лоше понаша није да се прође кроз сваки ред, већ да се посматра како он интерагује са оперативним системом и његовим дељеним библиотекама. Линукс нуди неколико моћних алата за ово: strace, ltrace, SystemTap, па чак и сам GDB преко специјализованих тачака за ухватање.

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 датотека која садржи садржај делова меморије процеса (стек, хип, мапирања) при завршетку, коју касније можете анализирати помоћу GDB-а као да сте били повезани у време пада система.

Да бисте ефикасно користили изводе основних података, морате осигурати да су они заиста генерисани и да их не блокирају ограничења ресурса или конфигурација. Ограничења шкољке као што су 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, посебно у областима где су људи раније парсирали његов терминални излаз. Уместо скраћивања текстуалног излаза, Ред Хет препоручује писање скрипти користећи GDB-ов Пајтон API или протокол Машинског интерфејса (MI), који су оба дизајнирана за програмску употребу.

Значајне промене укључују покретање инфериорних функција од стране GDBserver-а путем шкољке како би се омогућило проширење аргумената, уклањање подршке за GCJ (Java), ажурирану синтаксу за команде за избацивање симбола за одржавање и подешавања у руковању системским кореном ради боље подршке за даљинско отклањање грешака. Неке команде и режими, као што су HP-UX XDB компатибилност и remotebaud, су повучени или замењени генеричкијим еквивалентима као што су set serial baud.

Поред тога, GDB је увео ограничења као што су max-value-size да би се спречила неограничена алокација меморије при штампању веома великих вредности, промењен је начин контроле величине историје команди путем GDBHISTSIZE УМЕСТО HISTSIZEи додао ограничење за кандидате за завршетак путем set max-completions. Ове мере заштите помажу у избегавању замрзавања или прекомерне потрошње меморије приликом отклањања грешака у патолошким или оштећеним програмима.

Крајњи ефекат за C и C++ програмере на Линуксу је робуснији, скриптни дебагер који се може скалирати на огромне кодне базе и чудне сценарије кварова, под условом да сте упознати са ажурираним командама и дугмадима за конфигурацију. У комбинацији са модерним инфраструктурама компајлера као што су GCC и Clang/LLVM (и понудама као што је IBM Open XL C/C++ на Power-у), GDB чини окосницу моћног ланца алата за развој и решавање проблема сложеног изворног софтвера на Linux-у.

Избор правог компајлера и IDE-а, омогућавање DWARF информација за дебаговање и инсталирање debuginfo пакета, као и коришћење GDB, strace, ltrace, SystemTap и core-dump радних процеса, даје вам Linux C/C++ окружење које је брзо, транспарентно и погодно за највеће бекендове, чак и ако су ваши први утисци потицали из споре сесије дебаговања VS Code-а. Са правилном конфигурацијом и познавањем доступних алата, дебаговање на Линуксу не само да одговара удобности Висуал Студија на Виндоусу; у многим сценаријима, оно вам заправо даје финију контролу и дубљи увид у то како се ваше C и C++ апликације заиста понашају.