C- ja C++-ohjelmointiohjelmistot ja virheenkorjaustyökalut Linuxissa

Etusivu » Python » C- ja C++-ohjelmointiohjelmistot ja virheenkorjaustyökalut Linuxissa

Jos olet aiemmin käyttänyt Windowsia ja Visual Studiota ja yhtäkkiä päädyt valtavaan C- tai C++-koodikantaan Linuxissa, muutos voi tuntua rajulta. Satojen tuhansien rivien läpikäyminen GDB:llä esimerkiksi VS Coden kaltaisen editorin takana ja 30–60 sekunnin odottelu jokaista vaihetta kohden voi saada sinut miettimään, teetkö jotain todella väärin vai onko Linux-kehitys vain suunniteltu hidasta. Hyvä uutinen on, että nykyaikaiset Linux-työkaluketjut ja debuggerit ovat erittäin tehokkaita; sinun tarvitsee vain tietää, miten ne asennetaan ja mitkä työkalut sopivat suuriin C/C++-projekteihin.

Tämä opas opastaa sinua C/C++-kääntäjien, IDE:iden ja virheenkorjaustyökalujen maisemassa Linuxissa., (katso Opi Linux alusta alkaen), GCC:stä, Clang/LLVM:stä ja IBM Open XL C/C++:sta GDB:hen, Eclipseen, SystemTapiin, straceen, ltraceen ja edistyneisiin core-dump-työnkulkuihin. Matkan varrella käsittelemme myös klassisia oppimisympäristöjä (kuten Geany + GCC) ja näytämme konkreettisia vinkkejä virheenkorjauksen nopeuttamiseksi ja C- ja C++-kielillä Linux-kehityksen tekemiseksi paljon lähemmäksi Windowsissa tottunutta mukavuutta.

C- ja C++-kääntäjät Linuxissa: GCC, Clang/LLVM ja IBM Open XL

Linuxissa C:n ja C++:n referenssityökaluketju on edelleen GCC (GNU Compiler Collection), jonka C++-käyttöliittymänä toimii g++. Useimmat jakelut toimittavat GCC:n oletusarvoisesti, ja käytännössä kaikki tutoriaalit, koontijärjestelmät ja CI-putket olettavat sen olemassaolon. Yleensä käännetään komennoilla, kuten gcc C:lle ja g++ esimerkiksi C++:lle g++ -g -O2 main.cpp -o app rakentaa debugattava, optimoitu binääritiedosto.

Clang ja LLVM-ekosysteemi ovat kasvaneet tehokkaaksi vaihtoehdoksi GCC:lle Linuxissa, joka tarjoaa nopean kääntämisen, erinomaisen diagnostiikan ja monipuoliset työkalut (staattinen analyysi, koodin muotoilu, puhdistusohjelmat ja paljon muuta). Clang on C/C++-käyttöliittymä, joka on rakennettu LLVM:n päälle. LLVM on modulaarinen avoimen lähdekoodin kääntäjäinfrastruktuuri, joka tukee useita arkkitehtuureja ja kieliä ja jota suuri yhteisö ylläpitää aktiivisesti.

IBM Open XL C/C++ for Linux on Power on kaupallinen työkaluketju, joka integroi Clangin/LLVM:n tiiviisti IBM:n pitkäaikaiseen kääntäjien optimointiosaamiseen. IBM Power -järjestelmille suunnattu ohjelmisto hyödyntää nykyaikaisia ​​C/C++-kielen ominaisuuksia (mukaan lukien C++17), LLVM-vakio-optimointeja ja GCC-yhteensopivuutta tehokkaiden binääritiedostojen toimittamiseksi Power-laitteistossa. Tämä tarkoittaa, että saat LLVM-ekosysteemin edut sekä IBM:n kehittämät alustakohtaiset optimoinnit.

Vanhemmille ympäristöille IBM tarjoaa edelleen vanhempia XL C/C++ -kääntäjiä Linuxille., joten organisaatiot, joilla on olemassa olevia rakennusketjuja tai sertifiointirajoituksia, voivat jatkaa niiden käyttöä ja ottaa samalla vähitellen käyttöön Open XL C/C++:n uudemmissa työkuormissa.

Klassinen oppimisympäristö: GCC ja kevyet IDE:t

Jos olet vasta aloittamassa C:n tai C++:n käyttöä Linuxissa, erittäin yleinen ja tehokas ratkaisu on GCC ja kevyt IDE, kuten Geany. Geany on monialustainen (Linux ja Windows), nopea ja integroi perusominaisuudet, kuten projektinhallinnan, koontikomennot ja yksinkertaisen virheenkorjauksen ilman täysimittaisten raskaiden IDE-ympäristöjen aiheuttamaa lisärasitusta.

Monet pitkät C/C++-kurssit Linuxille suosittelevat juuri tätä yhdistelmää: GCC kääntäjäksi ja Geany kehitysympäristöksi. Tällaisten tutoriaalien avulla opit yleensä kielen perusasioista alkaen: mikä GNU-kääntäjä on ja miten sitä kutsutaan, miten ohjelma jäsennetään, miten työskennellään ehdollisten lausekkeiden, funktioiden, taulukoiden, merkkijonojen, osoittimien, rakenteiden, yhdisteiden, tiedosto-I/O:n kanssa ja lopulta C++:n oliopohjaisten käsitteiden, kuten periytymisen, operaattorien ylikuormituksen ja polymorfismin, kanssa.

Vaikka IDE-vaihtoehdot vaihtelevat, työkaluketjun taustalla olevat neuvot ovat yleensä yhdenmukaisia: käytä GCC:tä (tai g++:aa) eri alustoilla aina kun mahdollista. Linuxissa tämä on oletusarvo; Windowsissa ja macOS:ssä voit asentaa GCC:n MinGW:n, MSYS2:n, WSL:n, Homebrew'n tai vastaavien työkalujen kautta, mikä pitää työnkulun yhtenäisenä eri järjestelmissä ja helpottaa skriptien ja Makefile-tiedostojen jakamista.

Vaikka IDE abstraktoikin rakennusvaiheita, on tärkeää ymmärtää, että kyseessä on vain kutsu gcc or g++ Kulissien takana tehtävä työ on ratkaisevan tärkeää monimutkaisten koonti- tai suorituksenaikaisten ongelmien vianmäärityksessä. Vaihtoehdot kuten -g virheenkorjaustietoja, optimointitasoja, kuten -O0, -O2 or -O3ja merkintöjä varoitusten tai standardien noudattamisen säätämiseksi (-Wall, -std=c++17jne.) kaikki ovat erittäin tärkeitä hienovaraisten vikojen diagnosoinnissa.

Virheenkorjaus suurissa C++-koodikannoissa: VS Codesta natiiviin GDB:hen

Visual Studiosta Windowsissa Linuxiin siirtyvät kehittäjät aloittavat usein Visual Studio -koodilla ja GDB-pohjaisella laajennuksella ja huomaavat nopeasti, että debuggerin käyttöönotto voi olla tuskallisen hidasta suurissa taustajärjestelmissä. Ei ole ennenkuulumatonta, että jokaisessa vaiheessa on 30–60 sekunnin viiveitä, kun debugataan suuria asiakirjojen käsittely- tai toimitusjärjestelmiä, joissa on satoja tuhansia rivejä ja useita taustajärjestelmän komponentteja.

Tämä hidas käyttökokemus ei tyypillisesti johdu itse GDB:n rajoituksesta, vaan integraatiokerroksesta tai VS Coden ja taustalla olevan virheenkorjaajan välisestä kokoonpanosta. Virheenkorjauslaajennuksen ongelmat, keskeytyskohtien synkronointi, symbolitietojen lataus ja MI (Machine Interface) -komentojen käännös voivat kaikki osaltaan hidastaa monimutkaisia ​​reaalimaailman sovelluksia merkittävästi.

VS Coden C/C++-laajennuksessa on raportoitu tunnettuja pitkäaikaisia ​​ongelmia, jotka liittyvät GDB:n porrastettuun suorituskykyyn Linuxissa. Joillekin tiimeille tämä tarkoittaa, että VS Code on loistava editori, mutta ei välttämättä nopein vaihtoehto käyttöliittymäksi jättimäisten C++-palveluiden virheenkorjaukseen; vaihtoehtoja ovat esimerkiksi Googlen antigravitaatiokehitysympäristö ja natiiveja IDE-ympäristöjä on olemassa. Kun suorituskyky on kriittistä, monet insinöörit käyttävät takaisin suoraan GDB:tä tai siirtyvät natiiviin IDE-ympäristöön, joka on integroitu syvemmälle paikalliseen työkaluketjuun.

Jos siis huomaat, että jokainen VS Coden debug-istunnon vaihe Linuxissa kestää puoli minuuttia, älä oleta, että Linuxin debuggaus on luonnostaan ​​niin hidasta. Ennen luovuttamista kannattaa testata GDB:tä suoraan terminaalissa samalla binääritiedostolla ja vertailla sen toimintaa. Usein GDB:n sisällä liikkuminen on huomattavasti nopeampaa, mikä viittaa kokoonpanon tai laajennuksen pullonkaulaan pikemminkin kuin perustavanlaatuiseen käyttöjärjestelmän tai kääntäjän ongelmaan.

Suurissa Linux-pohjaisissa C++-kehitystyökaluissa suosittuja vaihtoehtoja mukavaan virheenkorjaukseen ovat Eclipse ja CDT (C/C++ Development Tooling), CLion, Qt Creator, KDevelop ja muut natiivit IDE:t, jotka integroituvat tiiviimmin GDB:hen ja paikalliseen järjestelmään. Nämä ympäristöt voivat tarjota lähdekoodin navigointia, seurantaikkunoita ja monipuolisia keskeytyskohtia käyttäen silti GDB:tä konepellin alla ilman kieliriippumattomien virheenkorjauskerrosten aiheuttamaa lisärasitusta.

Tietoa Linuxin virheenjäljityksestä: ELF, DWARF, debuginfo ja debugsource

Linuxissa käännetyt ohjelmat ja jaetut kirjastot tallennetaan yleensä ELF-tiedostoihin (Executable and Linkable Format), ja niihin liittyvät debug-tiedot koodataan DWARF-muotoon. DWARF sisältää metatiedot, joita debuggerit tarvitsevat konekoodin yhdistämiseen lähdekooditiedostoihin, rivinumeroihin, funktioihin, tyyppeihin ja muuttujiin.

Voit tarkastella DWARF-osioita ELF-binääritiedostossa työkaluilla, kuten readelf -w file, joka dumppaa raakat debug-tietueet. Vaikka DWARF-arvoa ei yleensä lueta manuaalisesti, tämä varmistaa, onko virheenkorjaustietoja saatavilla, ja siitä voi olla korvaamatonta apua GDB:n tai muiden työkalujen "symboleja ei ladattu" -tyyppisten ongelmien diagnosoinnissa.

Vanhempi debug-muoto nimeltä STABS on edelleen olemassa, mutta sitä pidetään vanhentuneena eikä sitä suositella nykyaikaisissa Linux-jakeluissa, kuten Red Hat Enterprise Linuxissa. GCC ja GDB tarjoavat parhaan mahdollisen tuen STABS:lle, mutta ekosysteemin keskeiset työkalut (esimerkiksi Valgrind tai elfutils) eivät välttämättä toimi oikein sen kanssa, minkä vuoksi DWARF:ia suositellaan vahvasti.

Koska debug-data on yleensä suuri, useimmat jakelut jakavat sen pääbinääreistä erillisiin debuginfo- ja debugsource-paketteihin. Oletusarvoisesta arkistosta asennettavasta suoritettavasta tiedostosta poistetaan yleensä debug-symbolit levytilan säästämiseksi ja muistin käytön vähentämiseksi, kun taas vastaava debuginfo-paketti sisältää DWARF-tiedot ja valinnaisesti debugsource sisältää vastaavat lähdekoodit.

RHEL-järjestelmissä ja vastaavissa järjestelmissä pyydät debug-tietoja nimenomaisesti käännösaikana käyttämällä -g kun rakennat omia projektejasi GCC:llä. Paketeista asennettujen järjestelmä- ja kolmannen osapuolen kirjastojen osalta voit hankkia asiaankuuluvat debuginfo ja debugsource paketit erikoistuneista virheenkorjausrepositorioista, joihin GDB usein vihjaa suoraan, kun se huomaa puuttuvia symboleja virheenkorjausistunnon aikana.

Järjestelmäbinäärien debuginfo-tiedostojen asentaminen ja paikantaminen

Kun debugaat C- tai C++-ohjelmia, jotka ovat riippuvaisia ​​järjestelmäkirjastoista, debuginfo-tiedoston asentaminen näille kirjastoille voi tehdä ratkaisevan eron jäljitysten ja muuttujien tarkastuksen laadussa. Ilman sitä näet jaetuissa kirjastoissa vain raakaosoitteita tai vääristyneitä funktioiden nimiä; sen avulla saat rivitarkat pinonjäljet ​​ja symboliset muuttujien nimet.

RHEL-tyyppisissä jakeluissa GNU Debugger (GDB) voi automaattisesti havaita, milloin ladatun objektin debug-tiedot puuttuvat, ja ehdottaa konkreettista komentoa tarvittavien tietojen asentamiseksi. debuginfo paketti kautta dnf. Suoritat vain suositellun dnf debuginfo-install ... komennon, vahvista pyydettäessä, niin järjestelmä noutaa ja asentaa istuntoasi varten tarvittavat symbolipaketit.

Jos automaattisia vihjeitä ei ole saatavilla, voit tunnistaa tarvittavan debuginfo-tiedoston manuaalisesti etsimällä binääri- tai kirjastotiedoston esimerkiksi seuraavilla työkaluilla: locate ja sitten kyselyn tekeminen RPM-tietokantaan. locate käsky tulee sieltä, mlocate paketti, joka sinun on ehkä asennettava ja alustettava. Kun sinulla on polku, voit kysyä, mikä paketti omistaa sen, ja asentaa sitten vastaavan debuginfo-variantin.

On tilanteita, joissa tietyn binääritiedoston asentanutta pakettia ei voida määrittää, esimerkiksi silloin, kun tiedosto on kopioitu manuaalisesti tai rakennettu paikallisesti ilman pakkaamista. Näissä tapauksissa sinun on ehkä palattava mukautettuihin symbolitiedostoihin tai, jos mahdollista, rakennettava binääritiedosto itse uudelleen käyttämällä -g käytössä, jotta GDB:llä on täydelliset virheenkorjaustiedot.

Muista, että debuginfo-tiedoston asentaminen jokaiselle järjestelmän kirjastolle on harvoin tarpeen ja se voi olla turhaa. Keskity ongelmaasi eniten vaikuttaviin moduuleihin: sovellusbinaariisi ja tiettyihin kirjastoihin, joista kaatuminen tai virheellinen toiminta johtuu, sen sijaan, että vetäisit virheenkorjauspaketteja koko käyttöjärjestelmälle.

GDB:n käyttö interaktiiviseen virheenkorjaukseen Linuxissa

GDB on keskeinen työkalu natiivien C- ja C++-sovellusten virheenkorjaukseen Linuxissa, ja se tarjoaa sekä komentorivikäyttöliittymän että integraatioiden kautta graafisia käyttöliittymiä, kuten Eclipse CDT:n. Red Hat Enterprise Linuxissa vakiojakelu sisältää täysin varustellun GDB:n sekä valinnaisia ​​graafisia käyttöliittymiä.

Ohjelman virheenkorjaukseen alusta alkaen käytetään tyypillisesti gdb ./program, määritä keskeytyspisteet tarpeen mukaan ja käynnistä sitten suoritus GDB:n sisällä komennolla run komento. Vaihtoehtoisesti voit liittää sen jo käynnissä olevaan ohjelmaan, jossa on gdb -p <pid> tai käynnistämällä GDB ja käyttämällä attach komento yhdessä prosessitunnuksen kanssa.

Jos GDB ei pysty päättelemään tietyn PID:n kohdetiedostoa liittämisen aikana, voit kertoa sille eksplisiittisesti, mitä binääritiedostoa käytetään, käyttämällä file komento ja jatka sitten debuggaamiseen. Tämä on erityisen hyödyllistä silloin, kun käsitellään mukautettuja käynnistysohjelmia, kääreskriptejä tai usean binäärisen tiedoston kokoonpanoja, joissa varsinainen suoritettava tiedostopolku ei ole ilmeinen.

Kun ohjelma on liitetty tai käynnistetty, voit ohjata sen kulkua komennoilla, kuten n (seuraava) s (askel), until, finish ja yksinkertaisesti c (jatka) samalla kun suljetaan debuggeri komennolla q kun valmis. Jokaisella näistä komennoista on tietty semantiikka sen suhteen, astuuko se funktion runkoon, suoritetaanko se tiettyyn riviin asti vai jatkuuko suoritus seuraavaan keskeytyskohtaan tai lopetukseen asti.

Tilan ymmärtämiseksi GDB tarjoaa monipuolisia introspektiokomentoja muuttujien, kutsupinojen, rekisterien ja muiden tarkasteluun sekä kontekstuaalista apua seuraavien kautta: help info ja vastaavia komentoja. Voit näyttää nykyisen lähderivin toiminnolla list, tulosta muuttujat, joilla on print, tutki pinottuja kehyksiä backtrace ja navigoi kehyksissä frame, up ja down.

Katkaisupisteet, tarkkailupisteet ja ehdot GDB:ssä

Todellisessa virheenkorjauksessa et juuri koskaan astu sokeasti pois main()Sen sijaan sijoitat strategisesti keskeytyspisteitä pysäyttääksesi ohjelman juuri niihin kohtiin, joissa käyttäytyminen muuttuu mielenkiintoiseksi. Vakiokomento break voit asettaa keskeytyskohtia joko tiedosto- ja rivinumeron tai funktion nimen mukaan, ja GDB keskeyttää suorituksen seuraavan osuman yhteydessä.

Voit esimerkiksi asettaa keskeytyskohdan tietylle lähdekoodiriville käyttämällä syntaksia, kuten break file.cpp:123, tai katkaise funktion alku käyttämällä break my_function. Kun keskeytyskohta saavutetaan, GDB pysäyttää ohjelman, jolloin voit tarkastella paikallisia muuttujia, tarkistaa kutsupinon ja päättää, haluatko astua sisään, astua yli vai jatkaa.

Ehdolliset keskeytyspisteet ovat korvaamattomia, kun vika ilmenee vasta useiden iteraatioiden jälkeen tai tiettyjen syöttöarvojen alapuolella. Voit liittää C- tai C++-kielellä kirjoitetun totuusarvon ehdon keskeytyskohtaan, jolloin GDB pysähtyy vain, kun ehto on tosi. Tämä vähentää merkittävästi tarpeettomia pysähdyksiä ja tehostaa virheenkorjaussilmukoita tai monimutkaisia ​​tilakoneita.

GDB tarjoaa tarkkailupisteitä (watchpoints), joiden avulla voidaan valvoa datan muutoksia koodinkulun sijaan. Nämä toiminnot aktivoituvat, kun lauseketta (usein muuttujaa) luetaan tai siihen kirjoitetaan. Komennoilla, kuten watch, rwatch (luettu) tai awatch (luku/kirjoitus) voit pysäyttää suorituksen täsmälleen silloin, kun tiettyä kenttää muutetaan tai siihen päästään käsiksi, mikä on erityisen hyödyllistä odottamattomien tilamuutosten jäljittämisessä.

Hallitset kaikkia keskeytyspisteitä ja tarkkailupisteitä komennoilla, kuten info breakpoints or info br, ja voit poistaa numeron tai sijainnin mukaan käyttämällä delete asianmukaisin argumentein. Tämä helpottaa aktiivisten keskeytyskohtien selkeän joukon ylläpitämistä ja estää sekaannuksia useiden moduulien tai istuntojen virheenkorjauksessa.

Monisäikeisten ja haarautuneiden prosessien virheenkorjaus

Säikeitä tai haarukoita laajasti hyödyntävien C- ja C++-ohjelmien virheenkorjaus vaatii hieman lisätietämystä siitä, miten GDB seuraa suorituskonteksteja. Oletusarvoisesti GDB nimeää nykyisen säikeen, ja useimmat komennot toimivat kyseisessä säikeessä, ellet vaihda säikettä erikseen käyttämällä thread ja säikeen tunniste.

Kun ohjelmasi haarautuu, asetus set detach-on-fork määrittää, seuraako GDB lasta vai vanhempaa prosessia ja miten se käsittelee ei-seuratun prosessin. Voit määrittää GDB:n joko pitämään hallinnan molemmista tai irrottautumaan automaattisesti toisesta puolesta riippuen siitä, onko vanhempi, lapsi vai molemmat olennaisia ​​analyysisi kannalta.

Uudemmat GDB-versiot ovat kehittäneet säikeiden numerointia ottamalla käyttöön alempiarvoisen säikeen tunnuksen sekä erillisen globaalin säikeen tunnuksen yhteensopivuuden takaamiseksi. Mukavuusmuuttuja $_thread ja Python API:t InferiorThread.num heijastavat nyt alempiarvoista numerointia, kun taas globaali tunniste on saatavilla kautta $_gthread ja InferiorThread.global_numvarmistaen, että vanhemmat, globaaleihin tunnisteisiin perustuvat työkalut toimivat edelleen.

Signaalinkäsittelyä monisäikeisessä virheenkorjauksessa on myös parannettu siten, että signaalit toimitetaan aina oikeaan säikeeseen. Jos vaihdat säiettä signaalin pysäyttäessä ohjelman ja yrität sitten jatkaa, GDB voi pyytää vahvistusta, mikä estää vahingossa tapahtuvan virheellisen toimituksen ja tekee signaaliin liittyvästä virheenkorjauksesta luotettavampaa.

Kaikki tämä tarkoittaa, että analysoitaessa lukkiutumisia, kilpailuja tai outoja signaalin laukaisemia kaatumisia, voit luottaa GDB:n säiemalliin oikean suorituspolun seuraamiseksi tarkasti ja hallitusti. Yhdessä keskeytyspisteiden, tarkkailupisteiden ja keskeytyspisteiden kanssa tämä mahdollistaa vankan monisäikeisen virheenkorjauksen jopa erittäin samanaikaisissa C++-palveluissa.

Järjestelmä- ja kirjastokutsujen jäljitys: strace, ltrace ja SystemTap

Joskus nopein tapa ymmärtää C- tai C++-ohjelman virheellisiä toimintoja ei ole käydä läpi jokaista riviä, vaan tarkkailla, miten ohjelma on vuorovaikutuksessa käyttöjärjestelmän ja sen jaettujen kirjastojen kanssa. Linux tarjoaa tähän useita tehokkaita työkaluja: stracen, ltracen, SystemTapin ja jopa itse GDB:n erikoistuneiden catchpointtien kautta.

strace apuohjelma jäljittää järjestelmäkutsuja – vuorovaikutusta ytimen kanssa, kuten open, read, write, mmap, execve ja niin edelleen – niiden parametrien ja paluuarvojen kanssa. Voit ajaa ohjelmasi läpi strace tai liitä käynnissä olevaan prosessiin PID:n perusteella, valinnaisesti suodattamalla näytettävät järjestelmäkutsut lausekkeilla, kuten -e trace=call ja sen hallinta, seurataanko haarautuneita vai säikeitettyjä lapsia -f.

Koska todelliset sovellukset lähettävät valtavan määrän järjestelmäkutsuja, jotka yhdistävät strace shell-työkaluilla, kuten tee on yleistä sekä tarkastella tulostetta reaaliajassa että tallentaa se analysointia varten. Tämä auttaa tunnistamaan puuttuvia tiedostoja, käyttöoikeusongelmia, odottamatonta verkon toimintaa tai muita käyttöjärjestelmätason ongelmia, jotka eivät välttämättä ole ilmeisiä itse koodista.

Täydentävä strace, ltrace keskittyy jaettujen kirjastojen funktioiden kutsuihin käyttäjätilassa ja näyttää dynaamisista objekteista vietyjen funktioiden kutsut ja paluuarvot. RHEL 8:ssa on tunnettu rajoitus, jonka vuoksi ltrace ei pysty jäljittämään tiettyjä järjestelmän suoritettavia tiedostoja, mutta se toimii normaalisti käyttäjän rakentamien binäärien kanssa. Tästä syystä se on arvokas työkalu sen ymmärtämiseen, miten ohjelmasi käyttää kirjastojen API-rajapintoja.

SystemTap on edistyneempi jäljityskehys, joka mahdollistaa mukautettuja tapahtumankäsittelijöitä sekä ytimen että käyttäjätilan tapahtumille käyttämällä omaa skriptikieltään. Sen käyttö voi olla monimutkaisempaa kuin stracen tai ltracen, mutta se skaalautuu paremmin ja tukee kehittynyttä suodatusta ja yhdistämistä. Mukavuuden vuoksi esimerkkiskripti nimeltä strace.stp toimitetaan SystemTapin kanssa matkimaan strace-tyyppistä käyttäytymistä SystemTapin infrastruktuuria käyttäen.

GDB itse voi osallistua jäljitykseen käyttämällä catchpoint-pisteitä järjestelmäkutsuille ja signaaleille komentojen, kuten catch syscall ja catch signal. Nämä aiheuttavat virheenkorjaajan pysäyttämisen aina, kun ohjelma suorittaa tiettyjä järjestelmäkutsuja tai vastaanottaa tiettyjä signaaleja, mikä voi olla erittäin kätevää, kun tarvitset tarkkaa ohjausta interaktiivisen virheenkorjauksen aikana.

Ydinvedokset ja jälkipuinti GDB:llä

Kun C- tai C++-sovellus kaatuu tai jumiutuu tavalla, jota on vaikea toistaa interaktiivisesti, ydinvedokset tarjoavat tilannekuvan sen muistista ja tilasta kriittisellä hetkellä. Ydinvedos on ELF-tiedosto, joka sisältää prosessin muistin osien (pinon, keon, määritysten) sisällön lopetushetkellä. Voit analysoida tätä myöhemmin GDB:llä ikään kuin olisit ollut yhteydessä kaatumisen aikana.

Jotta ydinvedoksia voitaisiin käyttää tehokkaasti, on varmistettava, että ne todella luodaan eivätkä resurssirajoitukset tai kokoonpano estä niiden toimintaa. Shell-rajoitukset, kuten ulimit -c voi estää ydintiedostojen luomisen; asettaen rajan unlimited poistaa kokorajoitukset, vaikka sinun kannattaa tarkistaa levytilan vaikutukset tuotantojärjestelmissä.

Nykyaikaisissa RHEL-järjestelmissä systemd-coredump hallinnoi ydinvedoksia läpinäkyvästi ja tallentaa ne keskitettyyn lokitiedostomaiseen sijaintiin sen sijaan, että ne jätettäisiin core tiedostot hajallaan hakemistoissa. coredumpctl työkalun avulla voit listata tallennetut kaatumiset, tarkastella niiden metatietoja ja viedä varsinaisen ydintiedoston valittuun polkuun tarkempaa analyysia varten.

Systemaattista kaatumisten sieppaustyönkulkua luotaessa on yleistä asentaa sos pakkaaminen ja käyttö sosreport luodaksesi tarball-tiedoston, joka sisältää järjestelmän asetukset ja lokit. Yhdessä vietyn ydintiedoston ja sovellusbinaarien kanssa tämä antaa sinulle kaiken tarvittavan kaatumisten analysointiin erillisellä koneella tai niiden siirtämiseen toiselle tiimille tai toimittajalle.

Voit jopa tarkoituksella laukaista ydinvedoksen vastaamattomalle prosessille lähettämällä sille keskeytyssignaalin tai käyttämällä työkaluja, kuten gcore, joka tyhjentää prosessin muistin sen ollessa vielä käynnissä. aikana gcore vedoksen jälkeen prosessi pysähtyy hetkeksi ja jatkaa sitten normaalia suoritusta, mikä mahdollistaa ongelmallisen tilan offline-analyysin ilman palvelun täydellistä keskeyttämistä.

Oikean suoritettavan tiedoston ja symbolien löytäminen ydinanalyysiä varten

Jotta ydinvedosta voisi analysoida mielekkäästi, GDB tarvitsee sekä ydinvedoksen että sen tuottaneen suoritettavan tiedoston (sekä kaikki asiaankuuluvat jaetut kirjastot). Tämä on tärkeää, koska eri versioista rakennetut yhteensopimattomat binäärit voivat johtaa harhaanjohtaviin jäljityksiin ja virheellisiin muuttujien asetteluihin.

Työkalut kuten coredumpctl info näyttää kunkin siepatun ytimen yksityiskohtaiset metatiedot, mukaan lukien pääsuoritettavan tiedoston polun ja binääritiedoston yksilöivän koontitunnuksen. Koontitunnus saattaa näyttää pitkältä heksadesimaalilukuhajautukselta, ja voit verrata sitä binääritiedoston paikallisen kopion koontitunnukseen varmistaaksesi, että ne ovat identtiset ennen GDB:n käynnistämistä.

Jos suoritettava tiedosto ja sen kirjastot ovat peräisin RPM-paketeista, voit käyttää sosreport ja pakettitietokannan hakemaan tarkalleen tarvittavat versiot. Joissakin tapauksissa voit jopa asentaa vastaavat paketit uudelleen erilliselle virheenkorjauskoneelle ja käyttää sitten GDB:n set sysroot kokoonpano osoittamaan sen peilattuun kirjastoasetteluun etätyylistä virheenkorjausta varten.

Kun sinulla on oikeat objektit, aloitat GDB-istunnon komennolla, kuten gdb /path/to/exe /path/to/core ja anna GDB:n ladata ydin. Jos joltain moduulilta puuttuu debuginfo-tiedosto, GDB näyttää viestejä, jotka vihjaavat, mitkä paketit tai symbolitiedostot sinun tulisi asentaa saadaksesi täyden symbolinäkyvyyden.

Jos sovelluksesi debug-symbolit toimitetaan erillisissä tiedostoissa pakettien sijaan, voit ladata ne eksplisiittisesti käyttämällä symbol-file komento GDB:n sisällä. Sinulla ei ole pakko olla debug-tietoja jokaisesta ytimen jaetusta kirjastosta; keskittyminen omaan sovellukseesi ja epäilyttäviin kirjastoihin riittää yleensä asiaankuuluvan pinon ja sen tilan rekonstruoimiseksi.

Kun analysoit ydinvedosta, muista, että ohjelman suoritusta ohjaavat komennot (kuten step tai continue) eivät ole enää järkeviä, koska järjestelmään ei liity aktiivista prosessia. Sen sijaan luotat tarkastuskomentoihin – pinokehyksien, paikallisten ja globaalien muuttujien, muistialueiden ja säikeiden tutkimiseen – päätelläksesi, miksi kaatuminen tapahtui tai mihin ohjelma jumiutui.

Edistyneet muistivedosskenaariot ja GDB-muutokset nykyaikaisessa RHEL:ssä

Tietyt korkean tietoturvan tai suorituskyvyn sovellukset merkitsevät osia muististaan ​​ei-dumpattavaksi käyttämällä lippuja, kuten VM_DONTDUMP, mikä estää kyseisen muistin kirjoittamisen ydintiedostoihin. Tämä suojaa arkaluonteisia tietoja (esimerkiksi kryptografisia avaimia tai taloudellisia tietoja) ja pienentää vedosten kokoa, mutta tekee täydellisestä offline-analyysistä vaikeampaa.

Jos sinulla on voimakas tarve tallentaa kaikki – mukaan lukien alueet, jotka normaalisti jätetään pois vedoksista – voit määrittää GDB:n jättämään huomiotta ei-vedosmerkinnän ja pakottamaan kattavan muistivedoksen. GDB tarjoaa vaihtoehtoja ohittamiseen VM_DONTDUMP ja kopioi koko prosessimuisti ydintiedostoon rikostutkintaa tai syvävirheenkorjausta varten.

Työkalujen puolella RHEL 8:n mukana toimitettu GDB-versio tuo mukanaan useita RHEL 7:ään verrattuna muutoksia, jotka rikkovat toimintoja ja lisäävät niiden toimintaa, erityisesti alueilla, joilla aiemmin jäsennettiin sen päätetulostetta. Tekstitulosteen kaavinnan sijaan Red Hat suosittelee skriptien kirjoittamista GDB:n Python API:n tai Machine Interface (MI) -protokollan avulla, jotka molemmat on suunniteltu ohjelmalliseen käyttöön.

Merkittäviä muutoksia ovat GDBserverin alempiarvoisten osioiden käynnistäminen komentotulkin kautta argumenttien laajentamisen mahdollistamiseksi, GCJ (Java) -tuen poistaminen, ylläpitosymbolivedoskomentojen syntaksin päivitys ja sysroot-käsittelyn muutokset etävirheenkorjauksen paremman tuen takaamiseksi. Jotkin komennot ja tilat, kuten HP-UX XDB -yhteensopivuus ja remotebaud, on poistettu käytöstä tai korvattu yleisemmillä vastineilla, kuten set serial baud.

Lisäksi GDB otti käyttöön rajoituksia, kuten max-value-size estääkseen rajattoman muistin allokoinnin erittäin suuria arvoja tulostettaessa, muutimme komentohistorian koon hallintaa GDBHISTSIZE sijasta HISTSIZEja lisäsi rajoituksen valmistuvien ehdokkaiden määrälle set max-completions. Nämä suojatoimet auttavat välttämään jumiutumisia tai liiallista muistin kulutusta patologisten tai vioittuneiden ohjelmien virheenkorjauksessa.

C- ja C++-kehittäjille Linuxissa nettovaikutus on vankempi, skriptattava debuggeri, joka skaalautuu valtaviin koodikantoihin ja outoihin virhetilanteisiin, edellyttäen, että olet tietoinen päivitetyistä komennoista ja määritysnuppeista. Yhdessä nykyaikaisten kääntäjäinfrastruktuurien, kuten GCC:n ja Clang/LLVM:n (ja tarjousten, kuten IBM Open XL C/C++ Powerilla), kanssa GDB muodostaa tehokkaan työkaluketjun selkärangan monimutkaisten natiiviohjelmistojen kehittämiseen ja vianmääritykseen Linuxissa.

Oikean kääntäjän ja IDE:n valitseminen, DWARF-virheenkorjaustietojen käyttöönotto ja debuginfo-pakettien asentaminen sekä GDB-, strace-, ltrace-, SystemTap- ja core-dump-työnkulkujen hyödyntäminen antaa sinulle Linux C/C++ -ympäristön, joka on nopea, läpinäkyvä ja sopii suurimmille taustajärjestelmille, vaikka ensivaikutelmasi perustuisivat hitaaseen VS Code -virheenkorjausistuntoon. Oikeilla kokoonpanoilla ja käytettävissä olevien työkalujen tuntemuksella virheenkorjaus Linuxissa ei ainoastaan ​​vastaa Visual Studion mukavuutta Windowsissa; monissa tilanteissa se itse asiassa antaa sinulle tarkemman hallinnan ja syvemmän näkyvyyden C- ja C++-sovellustesi todelliseen toimintaan.