C i C++ programski softver i alati za ispravljanje pogrešaka na Linuxu

Početna » Piton » C i C++ programski softver i alati za ispravljanje pogrešaka na Linuxu

Ako dolazite s Windows + Visual Studio iskustva i odjednom se nađete u ogromnoj C ili C++ kodnoj bazi na Linuxu, promjena može biti brutalna. Koračanje kroz stotine tisuća redaka s GDB-om iza editora poput VS Codea, čekajući 30-60 sekundi za svaki korak, može vas navesti da se zapitate radite li nešto užasno krivo ili je razvoj Linuxa jednostavno spor po dizajnu. Dobra vijest je da su moderni Linux alati i debuggeri izuzetno sposobni; samo trebate znati kako ih postaviti i koji alati odgovaraju velikim C/C++ projektima.

Ovaj vodič vas vodi kroz C/C++ kompajlere, IDE-ove i alate za otklanjanje pogrešaka na Linuxu., (vidi Savladajte Linux od nule), od GCC-a, Clang/LLVM-a i IBM Open XL C/C++ do GDB-a, Eclipsea, SystemTapa, stracea, ltracea i naprednih radnih procesa izrade izvadaka jezgre. Usput ćemo se dotaknuti i klasičnih postavki učenja (poput Geanyja + GCC-a) i pokazati konkretne savjete za ubrzavanje otklanjanja pogrešaka i približavanje razvoja Linuxa s C-om i C++ udobnosti na koju ste možda navikli na Windowsima.

Kompajleri za C i C++ na Linuxu: GCC, Clang/LLVM i IBM Open XL

Na Linuxu, referentni alat za C i C++ je i dalje GCC (GNU Compiler Collection), s g++ kao C++ prednjim dijelom. Većina distribucija isporučuje GCC prema zadanim postavkama, a gotovo svi tutorijali, sustavi za izgradnju i CI cjevovodi pretpostavljaju njegovu prisutnost. Obično se kompajlira s naredbama poput gcc za C i g++ za C++, na primjer g++ -g -O2 main.cpp -o app za izgradnju optimizirane binarne datoteke u kojoj se mogu ispravljati pogreške.

Clang i LLVM ekosustav su izrasli u moćnu alternativu GCC-u na Linuxu., nudeći brzu kompilaciju, izvrsnu dijagnostiku i bogat skup alata (statička analiza, formatiranje koda, sanitizatori i još mnogo toga). Clang je C/C++ front-end izgrađen na LLVM-u, modularnoj infrastrukturi kompajlera otvorenog koda koja podržava više arhitektura i jezika te koju aktivno održava velika zajednica.

IBM Open XL C/C++ za Linux na Poweru je komercijalni lanac alata koji čvrsto integrira Clang/LLVM s IBM-ovim dugogodišnjim iskustvom u optimizaciji kompajlera. Namijenjen IBM Power sustavima, koristi moderne značajke jezika C/C++ (uključujući C++17), standardne LLVM optimizacije i kompatibilnost s GCC-om kako bi isporučivao visokoučinkovite binarne datoteke na Power hardveru. To znači da dobivate prednosti LLVM ekosustava plus platformski prilagođene optimizacije koje je razvio IBM.

Za naslijeđena okruženja, IBM i dalje nudi starije XL C/C++ kompajlere za Linux., tako da organizacije s postojećim lancima izgradnje ili ograničenjima certifikacije mogu nastaviti koristiti te sustave dok postupno usvajaju Open XL C/C++ za novija opterećenja.

Klasična postavka učenja: GCC i lagani IDE-ovi

Ako tek počinjete s C-om ili C++-om na Linuxu, vrlo uobičajena i učinkovita konfiguracija je GCC plus lagani IDE poput Geanyja. Geany je višeplatformski (Linux i Windows), brz i integrira osnovne značajke poput upravljanja projektima, naredbi za izgradnju i jednostavnog otklanjanja pogrešaka bez opterećenja koje donose potpuni IDE-ovi.

Mnogi dugi C/C++ tečajevi za Linux preporučuju upravo ovu kombinaciju: GCC kao kompajler i Geany kao razvojno okruženje. Kroz takve tutorijale obično učite jezik od temelja: što je GNU kompajler i kako ga pozvati, kako strukturirati program, kako raditi s uvjetnim izrazima, funkcijama, nizovima, stringovima, pokazivačima, strukturama, unijama, ulazno/izlaznim operacijama datoteka i na kraju objektno orijentiranim konceptima poput nasljeđivanja, preopterećenja operatora i polimorfizma u C++-u.

Iako se izbor IDE-a razlikuje, osnovni savjeti za korištenje alata obično su dosljedni: koristite GCC (ili g++) na svim platformama kad god je to moguće. Na Linuxu je ovo zadana postavka; na Windowsima i macOS-u možete instalirati GCC putem MinGW-a, MSYS2, WSL-a, Homebrewa ili sličnih alata, održavajući ujednačen tijek rada na svim sustavima i olakšavajući dijeljenje skripti i Makefileova.

Čak i kada IDE apstrahira korake izgradnje, razumijevajući da jednostavno poziva gcc or g++ iza kulisa je ključno za otklanjanje pogrešaka u složenim problemima s izgradnjom ili izvođenjem. Opcije poput -g za informacije o otklanjanju pogrešaka, razine optimizacije poput -O0, -O2 or -O3i oznake za podešavanje upozorenja ili usklađenosti sa standardima (-Wall, -std=c++17itd.) sve je to od velike važnosti pri dijagnosticiranju suptilnih grešaka.

Otklanjanje pogrešaka u velikim C++ kodnim bazama: od VS koda do izvornog GDB-a

Razvojni programeri koji prelaze s Visual Studija na Windowsima na Linux često počinju s Visual Studio Codeom i GDB-baziranim proširenjem te brzo primjećuju da korištenje programa za ispravljanje pogrešaka može postati bolno sporo na velikim pozadinskim sustavima. Nije nečuveno imati kašnjenja od 30-60 sekundi na svakom koraku prilikom otklanjanja pogrešaka u velikim sustavima za obradu ili isporuku dokumenata sa stotinama tisuća redaka i mnogim pozadinskim komponentama.

Ovo sporo iskustvo obično nije ograničenje samog GDB-a, već integracijskog sloja ili konfiguracije između VS koda i temeljnog programa za ispravljanje pogrešaka. Problemi u proširenju za otklanjanje pogrešaka, način sinkronizacije točaka prekida, način učitavanja informacija o simbolima i način prevođenja MI (strojnog sučelja) naredbi mogu doprinijeti masovnim usporavanjima u složenim aplikacijama iz stvarnog svijeta.

Poznati su dugogodišnji problemi prijavljeni u VS Code C/C++ ekstenziji vezani uz performanse steppinga s GDB-om na Linuxu. Za neke timove to znači da je VS Code odličan kao editor, ali ne nužno i najbrža opcija kao front-end za otklanjanje pogrešaka u ogromnim C++ servisima; alternative poput Google Antigravity IDE i postoje izvorni IDE-ovi. Kada su performanse ključne, mnogi inženjeri se vraćaju izravnom korištenju GDB-a ili prelaze na izvorni IDE koji je dublje integriran s lokalnim alatima.

Dakle, ako ustanovite da svaki korak u vašoj VS Code sesiji otklanjanja pogrešaka na Linuxu traje pola minute, nemojte pretpostavljati da je otklanjanje pogrešaka u Linuxu inherentno tako sporo. Prije odustajanja, vrijedi testirati GDB u terminalu izravno na istoj binarnoj datoteci i usporediti ponašanje. Često je ulazak u GDB znatno brži, što ukazuje na usko grlo konfiguracije ili proširenja, a ne na temeljni problem OS-a ili kompajlera.

U velikim C++ trgovinama na Linuxu, popularne alternative za udobno ispravljanje pogrešaka uključuju Eclipse s CDT-om (C/C++ Development Tooling), CLion, Qt Creator, KDevelop i druga izvorna IDE-a koja se čvršće integriraju s GDB-om i lokalnim sustavom. Ova okruženja mogu pružiti navigaciju izvornim kodom, prozore za praćenje i bogate točke prekida, a istovremeno koristiti GDB "u nastavku" bez opterećenja slojeva za otklanjanje pogrešaka neovisnih o jeziku.

Informacije o otklanjanju grešaka na Linuxu: ELF, DWARF, debuginfo i debugsource

Na Linuxu, kompilirani programi i dijeljene biblioteke obično se pohranjuju u ELF (Executable and Linkable Format) datotekama, a njihove povezane informacije o otklanjanju pogrešaka kodirane su u DWARF formatu. DWARF sadrži metapodatke koje debuggeri trebaju za mapiranje strojnog koda natrag u izvorne datoteke, brojeve redaka, funkcije, tipove i varijable.

Možete pregledati DWARF sekcije u ELF binarnoj datoteci pomoću alata poput readelf -w file, koji ispisuje sirove zapise o otklanjanju pogrešaka. Iako se DWARF obično ne čita ručno, ovo potvrđuje jesu li prisutne informacije za otklanjanje pogrešaka i može biti neprocjenjivo za dijagnosticiranje problema tipa "nema učitanih simbola" u GDB-u ili drugim alatima.

Stariji format za otklanjanje pogrešaka pod nazivom STABS još uvijek postoji, ali se smatra zastarjelim i ne preporučuje se na modernim Linux distribucijama kao što je Red Hat Enterprise Linux. GCC i GDB pružaju najbolju moguću podršku za STABS, ali ključni alati u ekosustavu (na primjer Valgrind ili elfutils) možda neće ispravno raditi s njim, zbog čega se DWARF toplo preporučuje.

Budući da podaci za otklanjanje pogrešaka obično budu veliki, većina distribucija ih odvaja od glavnih binarnih datoteka u odvojene pakete debuginfo i debugsource. Izvršna datoteka koju instalirate iz zadanog repozitorija obično je očišćena od simbola za debug kako bi se uštedio prostor na disku i smanjio memorijski otisak, dok odgovarajući debuginfo paket sadrži DWARF podatke, a opcionalno, debugsource uključuje odgovarajuće izvore.

Na RHEL-u i sličnim sustavima, eksplicitno zahtijevate informacije o debugiranju tijekom kompajliranja pomoću -g prilikom izrade vlastitih projekata s GCC-om. Za sistemske i biblioteke trećih strana instalirane iz paketa, možete dobiti relevantne debuginfo i debugsource paketi iz specijaliziranih repozitorija za otklanjanje pogrešaka, često izravno na koje ukazuje GDB kada primijeti nedostajuće simbole tijekom sesije otklanjanja pogrešaka.

Instaliranje i lociranje debuginfo-a za sistemske binarne datoteke

Prilikom otklanjanja pogrešaka u C ili C++ programima koji ovise o sistemskim bibliotekama, instaliranje debuginfo za te biblioteke može napraviti ogromnu razliku u kvaliteti povratnih tragova i inspekcije varijabli. Bez njega, u dijeljenim bibliotekama vidite samo sirove adrese ili iskrivljena imena funkcija; s njim dobivate linijski precizne tragove stoga i simbolička imena varijabli.

Na distribucijama sličnim RHEL-u, GNU Debugger (GDB) može automatski otkriti kada nedostaju informacije o otklanjanju grešaka za učitani objekt i predložiti konkretnu naredbu za instaliranje potrebnih debuginfo paket putem dnf. Jednostavno pokrenete preporučeno dnf debuginfo-install ... naredbu, potvrdite kada se to od vas zatraži, a sustav će dohvatiti i instalirati pakete simbola potrebne za vašu sesiju.

Ako automatski savjeti nisu dostupni, možete ručno identificirati potrebne debuginfo-e pronalaženjem binarne ili bibliotečne datoteke pomoću alata kao što su locate a zatim upit RPM bazi podataka. The locate naredba dolazi od mlocate paket, koji ćete možda trebati instalirati i inicijalizirati, a nakon što dobijete putanju, možete pitati koji ga paket posjeduje, a zatim instalirati odgovarajuću debuginfo varijantu.

Postoje situacije u kojima se ne može utvrditi paket koji je instalirao određenu binarnu datoteku, na primjer kada je datoteka ručno kopirana ili izgrađena na mjestu bez pakiranja. U tim slučajevima, možda ćete se morati vratiti na prilagođene datoteke simbola ili, ako je moguće, sami ponovno izgraditi binarnu datoteku pomoću -g omogućeno tako da GDB ima potpune podatke za otklanjanje pogrešaka.

Imajte na umu da instaliranje debuginfo datoteke za svaku pojedinu biblioteku u sustavu rijetko je potrebno i može biti rasipno. Usredotočite se na module koji su najrelevantniji za vaš problem: binarne datoteke vaše aplikacije i specifične biblioteke iz kojih potječe rušenje ili neispravno ponašanje, umjesto da povlačite pakete za otklanjanje pogrešaka za cijeli OS.

Korištenje GDB-a za interaktivno otklanjanje pogrešaka na Linuxu

GDB je središnji alat za otklanjanje pogrešaka izvornih C i C++ aplikacija na Linuxu, koji nudi i sučelje naredbenog retka i, putem integracija, grafičke prednje dijelove poput Eclipse CDT-a. Na Red Hat Enterprise Linuxu, standardna distribucija uključuje potpuno opremljeni GDB zajedno s opcionalnim grafičkim korisničkim sučeljima.

Za otklanjanje grešaka u programu od samog početka, obično se poziva gdb ./program, konfigurirajte točke prekida prema potrebi, a zatim pokrenite izvršavanje unutar GDB-a s run naredba. Alternativno, možete se pridružiti programu koji već radi s gdb -p <pid> ili pokretanjem GDB-a i korištenjem attach naredbu zajedno s ID-om procesa.

Ako GDB ne može zaključiti ciljnu izvršnu datoteku za zadani PID tijekom pričvršćivanja, možete mu eksplicitno reći koju binarnu datoteku treba koristiti putem file naredbu, a zatim nastavite s otklanjanjem pogrešaka. Ovo je posebno korisno kada imate posla s prilagođenim pokretačima, omotačkim skriptama ili višebinarnim postavkama gdje stvarna putanja izvršne datoteke nije očita.

Nakon što se poveže ili pokrene, možete kontrolirati tok programa naredbama poput n (sljedeći), s (korak), until, finish i to jednostavno c (nastavi), prilikom zatvaranja programa za ispravljanje pogrešaka s q kada je gotovo. Svaka od ovih naredbi ima specifičnu semantiku o tome ulazi li u tijela funkcija, izvršava li se do zadanog retka ili nastavlja izvršavanje do sljedeće točke prekida ili završetka.

Za razumijevanje stanja, GDB pruža bogate introspekcijske naredbe za pregled varijabli, stogova poziva, registara i još mnogo toga, a također nudi kontekstualnu pomoć putem help info i slične naredbe. Trenutni izvorni redak možete prikazati pomoću list, ispišite varijable s print, istražite okvire snopa s backtrace i navigirajte okvirima pomoću frame, up i down.

Točke prekida, točke praćenja i uvjeti u GDB-u

U stvarnom otklanjanju pogrešaka, gotovo nikada ne odstupate slijepo od main(); umjesto toga, strateški postavljate točke prekida kako biste zaustavili program upravo tamo gdje ponašanje postaje zanimljivo. Standardna naredba break omogućuje vam postavljanje točaka prekida prema broju datoteke i retka ili prema nazivu funkcije, a GDB će pauzirati izvršavanje pri sljedećem pogotku.

Na primjer, možete postaviti točku prekida na određenom retku izvornog koda koristeći sintaksu kao što je break file.cpp:123ili prekid na početku funkcije s break my_function. Kada se dostigne lokacija breakpointa, GDB zaustavlja program, omogućujući vam da pregledate lokalne varijable, provjerite stog poziva i odlučite hoćete li se uključiti, preći preko ili nastaviti.

Uvjetne točke prekida su neprocjenjive kada se greška pojavi tek nakon mnogo iteracija ili pod određenim ulaznim vrijednostima. Booleov uvjet napisan u C-u ili C++-u možete povezati s točkom prekida tako da GDB zaustavlja rad samo kada se uvjet isplati, što dramatično smanjuje nepotrebna zaustavljanja i čini petlje za otklanjanje pogrešaka ili složene automate stanja mnogo učinkovitijima.

Za praćenje promjena u podacima, a ne toka koda, GDB nudi točke praćenja koje se aktiviraju kada se izraz (često varijabla) čita iz njega ili u njega zapisuje. S naredbama poput watch, rwatch (čitaj) ili awatch (čitanje/pisanje), možete zaustaviti izvršavanje točno kada se određeno polje izmijeni ili mu se pristupi, što je posebno korisno u praćenju neočekivanih promjena stanja.

Svim točkama prekida i točkama praćenja upravljate putem naredbi kao što su info breakpoints or info br, a možete brisati po broju ili lokaciji pomoću delete s odgovarajućim argumentima. To olakšava održavanje čistog skupa aktivnih točaka prekida i sprječava zbrku prilikom otklanjanja pogrešaka u više modula ili sesija.

Rješavanje pogrešaka u višenitnim i račvastim procesima

Otklanjanje grešaka u C i C++ programima koji intenzivno koriste niti ili forkove zahtijeva dodatno razumijevanje načina na koji GDB prati kontekste izvršavanja. Prema zadanim postavkama, GDB označava trenutnu nit i većina naredbi radi na toj niti osim ako izričito ne prebacite pomoću thread i identifikator niti.

Kada se vaš program račva, postavka set detach-on-fork određuje prati li GDB dijete ili roditelja i kako postupa s procesom koji se ne prati. GDB možete konfigurirati da zadrži kontrolu nad obje strane ili da se automatski odvoji od jedne, ovisno o tome jesu li roditelj, dijete ili oboje relevantni za vašu analizu.

Novije verzije GDB-a razvile su način numeriranja niti, uvodeći ID za svaku inferiornu nit zajedno s zasebnim globalnim ID-om niti radi kompatibilnosti. Varijabla praktičnosti $_thread i Python API-je InferiorThread.num sada odražavaju numeriranje po inferiornim elementima, dok je globalni identifikator dostupan putem $_gthread i InferiorThread.global_num, osiguravajući da stariji alati temeljeni na globalnim ID-ovima nastave raditi.

Obrada signala u višenitnom otklanjanju pogrešaka također je poboljšana tako da se signali uvijek isporučuju ispravnoj niti. Ako promijenite nit nakon što signal zaustavi program, a zatim pokušate nastaviti, GDB može zatražiti potvrdu, sprječavajući slučajnu pogrešnu isporuku i čineći otklanjanje pogrešaka vezanih uz signal pouzdanijim.

Sve to znači da se prilikom analize zastoja, utrka ili neobičnih rušenja izazvanih signalima možete osloniti na GDB-ov model niti kako biste pratili ispravan put izvršenja s preciznom kontrolom. U kombinaciji s točkama prekida, točkama praćenja i točkama uhvaćenja, ovo omogućuje robusno višenitno otklanjanje pogrešaka čak i u C++ servisima s visokom koncentracijom.

Pozivi sustava za praćenje i biblioteke: strace, ltrace i SystemTap

Ponekad najbrži način da se shvati zašto se C ili C++ program loše ponaša nije pregledavanje svakog retka, već promatranje kako on komunicira s operativnim sustavom i njegovim dijeljenim bibliotekama. Linux nudi nekoliko moćnih alata za to: strace, ltrace, SystemTap, pa čak i sam GDB putem specijaliziranih catchpointova.

The strace Uslužni program prati sistemske pozive - interakcije s kernelom kao što su open, read, write, mmap, execve i tako dalje - zajedno s njihovim parametrima i povratnim vrijednostima. Svoj program možete pokrenuti putem strace ili se pridružuje pokrenutom procesu pomoću PID-a, opcionalno filtrirajući koje sistemske pozive prikazati pomoću izraza poput -e trace=call i kontrolirati treba li pratiti račvastu ili navojnu djecu s -f.

Budući da stvarne aplikacije izdaju ogroman broj sistemskih poziva, kombinirajući strace s alatima za ljuske poput tee Uobičajeno je i pregledavanje izlaza uživo i pohranjivanje istog za analizu. To vam pomaže identificirati nedostajuće datoteke, probleme s dozvolama, neočekivano ponašanje mreže ili druge probleme na razini operativnog sustava koji možda nisu očiti iz samog koda.

Dopunjavanje strace, ltrace fokusira se na pozive funkcija dijeljene biblioteke u korisničkom prostoru, prikazujući pozive i povratne vrijednosti za izvezene funkcije iz dinamičkih objekata. Na RHEL-u 8 postoji poznato ograničenje gdje ltrace ne može pratiti određene izvršne datoteke sustava, ali radi normalno za binarne datoteke koje su izradili korisnici, što ga čini vrijednim alatom za razumijevanje kako vaš program koristi API-je biblioteka.

SystemTap je napredniji okvir za praćenje koji omogućuje prilagođene rukovatelje događajima za događaje kernela i korisničkog prostora koristeći vlastiti skriptni jezik. Može biti složeniji za korištenje od strace ili ltrace, ali se bolje skalira i podržava sofisticirano filtriranje i agregaciju. Radi lakšeg snalaženja, primjer skripte pod nazivom strace.stp Dolazi sa SystemTapom kako bi oponašao ponašanje slično straceu koristeći SystemTapovu infrastrukturu.

Sam GDB može sudjelovati u praćenju korištenjem točaka za praćenje sistemskih poziva i signala, putem naredbi poput catch syscall i catch signal. Zbog toga se izvršavanje debuggera zaustavlja kad god program izvrši određene sistemske pozive ili primi određene signale, što može biti vrlo korisno kada vam je potrebna precizna kontrola tijekom interaktivnog debugiranja.

Izvještaji jezgre i post mortem otklanjanje pogrešaka s GDB-om

Kada se C ili C++ aplikacija sruši ili zamrzne na način koji je teško interaktivno reproducirati, izvaci osnovnih podataka pružaju snimku memorije i stanja aplikacije u kritičnom trenutku. Izvadak jezgre (core dump) je ELF datoteka koja sadrži sadržaj dijelova memorije procesa (stog, hrpa, mapiranja) prilikom završetka, koju kasnije možete analizirati pomoću GDB-a kao da ste bili spojeni u trenutku pada.

Za učinkovito korištenje osnovnih izvadaka podataka, morate osigurati da su oni stvarno generirani i da ih ne blokiraju ograničenja resursa ili konfiguracija. Ograničenja ljuske kao što su ulimit -c može spriječiti stvaranje osnovnih datoteka; postavljanje ograničenja na unlimited uklanja ograničenja veličine, iako biste trebali provjeriti implikacije na prostor na disku u produkcijskim sustavima.

Na modernim RHEL sustavima, systemd-coredump transparentno upravlja osnovnim izvatcima i pohranjuje ih na centraliziranoj lokaciji sličnoj dnevniku umjesto da ih ostavlja core datoteke razasute po direktorijima. The coredumpctl Alat vam omogućuje popis zabilježenih rušenja, pregled njihovih metapodataka i izvoz stvarne glavne datoteke u odabranu putanju za dublju analizu.

Prilikom stvaranja sustavnog tijeka rada za snimanje rušenja, uobičajeno je instalirati sos pakiranje i korištenje sosreport za generiranje tarballa s konfiguracijom sustava i zapisnicima. U kombinaciji s izvezenom osnovnom datotekom i binarnim datotekama aplikacije, ovo vam daje sve što je potrebno za analizu rušenja na zasebnom računalu ili njihovo prepuštanje drugom timu ili dobavljaču.

Možete čak i namjerno pokrenuti izvještavanje o stanju jezgre za proces koji ne reagira slanjem signala za prekid ili korištenjem alata poput gcore, koji prazne memoriju procesa dok je on još u izvođenju. Tijekom gcore dump, proces se nakratko pauzira, a zatim nastavlja normalno izvršavanje, omogućujući izvanmrežnu analizu problematičnog stanja bez potpunog prekida usluge.

Pronalaženje prave izvršne datoteke i simbola za analizu jezgre

Za smislenu analizu izvatka jezgre, GDB-u su potrebni i jezgra datoteke i točna izvršna datoteka (plus sve relevantne dijeljene biblioteke) koja ju je generirala. To je važno jer neusklađene binarne datoteke – izgrađene od različitih verzija – mogu dovesti do zavaravajućih povratnih tragova i neispravnih rasporeda varijabli.

Alati poput coredumpctl info prikaži detaljne metapodatke za svaku snimljenu jezgru, uključujući put do glavne izvršne datoteke i ID verzije koji jedinstveno identificira binarnu datoteku. ID verzije može izgledati kao dugi heksadecimalni hash, a možete ga usporediti s ID-om verzije vaše lokalne kopije binarne datoteke kako biste bili sigurni da su identični prije pokretanja GDB-a.

Ako izvršna datoteka i njezine biblioteke dolaze iz RPM paketa, možete koristiti sosreport i bazu podataka paketa za dohvaćanje točnih potrebnih verzija. U nekim slučajevima, možete čak i ponovno instalirati odgovarajuće pakete na namjenskom računalu za otklanjanje pogrešaka, a zatim koristiti GDB-ove set sysroot konfiguracija kako bi se usmjerila na zrcaljeni raspored biblioteke za udaljeno otklanjanje pogrešaka.

Nakon što imate ispravne objekte, pokrećete GDB sesiju naredbom kao što je gdb /path/to/exe /path/to/core i pustite GDB da učitava jezgru. Ako za bilo koji modul nedostaju debuginfo podaci, GDB će prikazati poruke koje ukazuju na to koje pakete ili datoteke simbola trebate instalirati kako biste dobili potpunu vidljivost simbola.

Ako su simboli za otklanjanje pogrešaka vaše aplikacije dostupni u zasebnim datotekama, a ne putem paketa, možete ih eksplicitno učitati pomoću symbol-file naredba unutar GDB-a. Niste obvezni imati informacije za otklanjanje pogrešaka za svaku pojedinu dijeljenu biblioteku u jezgri; fokusiranje na vlastitu aplikaciju i sumnjive biblioteke obično je dovoljno za rekonstrukciju relevantnog stoga i stanja.

Prilikom analize izvatka iz jezgre, imajte na umu da naredbe za kontrolu izvršavanja programa (poput step ili continue) više nemaju smisla jer nije pridružen aktivni proces. Umjesto toga, oslanjate se na naredbe za inspekciju - ispitivanje okvira stoga, lokalnih i globalnih varijabli, memorijskih regija i niti - kako biste zaključili zašto se dogodio pad ili gdje je program zapeo.

Napredni scenariji memorijskog dump-a i promjene GDB-a na modernom RHEL-u

Određene aplikacije visoke sigurnosti ili visokih performansi označavaju dijelove svoje memorije kao one koje se ne mogu ispisati pomoću zastavica kao što su VM_DONTDUMP, što sprječava upisivanje te memorije u osnovne datoteke. To štiti osjetljive podatke (na primjer, kriptografske ključeve ili financijske zapise) i smanjuje veličinu izvatka, ali otežava potpunu izvanmrežnu analizu.

Ako imate snažnu potrebu za snimanjem svega - uključujući područja koja su inače isključena iz dumpova - možete konfigurirati GDB da ignorira zastavicu ne-dump i prisili sveobuhvatni dump memorije. GDB nudi opcije za poništavanje VM_DONTDUMP i ispisati cijelu memoriju procesa u glavnu datoteku za forenziku ili dubinsko otklanjanje pogrešaka.

Što se tiče alata, GDB verzija koja dolazi s RHEL-om 8 uvodi niz promjena u ponašanju i prekidima u usporedbi s RHEL-om 7, posebno u područjima gdje su ljudi prije parsirali njegov terminalni izlaz. Umjesto struganja tekstualnog izlaza, Red Hat preporučuje pisanje skripti pomoću GDB-ovog Python API-ja ili protokola Machine Interface (MI), koji su oba dizajnirana za programsku upotrebu.

Značajne promjene uključuju pokretanje inferiornih naredbi putem ljuske od strane GDBservera kako bi se omogućilo proširenje argumenata, uklanjanje podrške za GCJ (Java), ažuriranu sintaksu za naredbe za održavanje simbola i prilagodbe u rukovanju sysrootom radi bolje podrške za udaljeno otklanjanje pogrešaka. Neke naredbe i načini rada, kao što su HP-UX XDB kompatibilnost i remotebaud, su ukinuti ili zamijenjeni generičkijim ekvivalentima poput set serial baud.

Osim toga, GDB je uveo ograničenja poput max-value-size kako bi se spriječila neograničena alokacija memorije pri ispisu vrlo velikih vrijednosti, promijenjen je način kontrole veličine povijesti naredbi putem GDBHISTSIZE umjesto HISTSIZEi dodao ograničenje za kandidate za završetak putem set max-completions. Ove zaštitne mjere pomažu u izbjegavanju zamrzavanja ili prekomjerne potrošnje memorije prilikom otklanjanja pogrešaka u patološkim ili oštećenim programima.

Krajnji učinak za C i C++ developere na Linuxu je robusniji, skriptni program za ispravljanje pogrešaka koji se skalira na ogromne kodne baze i čudne scenarije kvarova, pod uvjetom da ste svjesni ažuriranih naredbi i konfiguracijskih gumba. U kombinaciji s modernim infrastrukturama kompajlera poput GCC-a i Clang/LLVM-a (i ponudama kao što je IBM Open XL C/C++ na Poweru), GDB čini okosnicu moćnog lanca alata za razvoj i rješavanje problema složenog izvornog softvera na Linuxu.

Odabir pravog kompajlera i IDE-a, omogućavanje DWARF informacija za otklanjanje grešaka i instaliranje debuginfo paketa te korištenje GDB, strace, ltrace, SystemTap i core-dump radnih procesa daje vam Linux C/C++ okruženje koje je brzo, transparentno i prikladno za najveće backendove, čak i ako su vaši prvi dojmovi došli iz spore sesije otklanjanja grešaka VS Codea. Uz pravu konfiguraciju i poznavanje dostupnih alata, otklanjanje pogrešaka na Linuxu ne samo da odgovara udobnosti Visual Studija na Windowsima; u mnogim scenarijima, zapravo vam daje finiju kontrolu i dublji uvid u to kako se vaše C i C++ aplikacije stvarno ponašaju.