Programari de programació en C i C++ i eines de depuració a Linux

Inici » Python » Programari de programació en C i C++ i eines de depuració a Linux

Si tens experiència en Windows + Visual Studio i de sobte acabes en una base de codi C o C++ enorme a Linux, el canvi pot semblar brutal. Recórrer centenars de milers de línies amb GDB darrere d'un editor com VS Code, esperant entre 30 i 60 segons per a cada pas, et pot fer preguntar si estàs fent alguna cosa terriblement malament o si el desenvolupament de Linux és simplement lent per disseny. La bona notícia és que les cadenes d'eines i els depuradors moderns de Linux són extremadament capaços; només cal saber com configurar-los i quines eines s'adapten a projectes grans de C/C++.

Aquesta guia us guiarà pel panorama dels compiladors, IDE i eines de depuració de C/C++ a Linux (vegeu Master Linux from scratch ), des de GCC, Clang/LLVM i IBM Open XL C/C++ fins a GDB, Eclipse, SystemTap, strace, ltrace i fluxos de treball avançats de core-dump. Durant el camí, també tractarem les configuracions d'aprenentatge clàssiques (com ara Geany + GCC) i mostrarem consells concrets per accelerar la depuració i fer que el desenvolupament de Linux amb C i C++ sigui molt més proper a la comoditat a la qual esteu acostumats a Windows.

Compiladors per a C i C++ a Linux: GCC, Clang/LLVM i IBM Open XL

A Linux, la cadena d'eines de referència per a C i C++ continua sent GCC (GNU Compiler Collection), amb g++ com a front-end de C++. La majoria de distribucions inclouen GCC per defecte, i pràcticament tots els tutorials, sistemes de compilació i canals de CI assumeixen la seva presència. Normalment compileu amb ordres com ara gcc per a C i g++ per a C++, per exemple g++ -g -O2 main.cpp -o app per construir un binari depurable i optimitzat.

Clang i l'ecosistema LLVM s'han convertit en una potent alternativa a GCC a Linux , oferint una compilació ràpida, un diagnòstic excel·lent i un conjunt ric d'eines (anàlisi estàtica, formatació de codi, sanejadors i més). Clang és el front-end de C/C++ construït sobre LLVM, una infraestructura de compilació modular de codi obert que admet múltiples arquitectures i llenguatges i que és mantinguda activament per una gran comunitat.

IBM Open XL C/C++ per a Linux a Power és una cadena d'eines comercial que integra estretament Clang/LLVM amb l'experiència de llarga durada d'IBM en optimització de compiladors. Dirigit als sistemes IBM Power, aprofita les funcions modernes del llenguatge C/C++ (inclòs C++17), les optimitzacions LLVM estàndard i la compatibilitat amb GCC per oferir binaris d'alt rendiment en maquinari Power. Això significa que obteniu els avantatges de l'ecosistema LLVM a més de les optimitzacions ajustades a la plataforma desenvolupades per IBM.

Per a entorns antics, IBM encara proporciona els compiladors XL C/C++ més antics per a Linux , de manera que les organitzacions amb cadenes de compilació o restriccions de certificació existents poden continuar utilitzant-los mentre adopten gradualment Open XL C/C++ per a càrregues de treball més noves.

Configuració d'aprenentatge clàssica: GCC i IDE lleugers

Si tot just comenceu amb C o C++ a Linux, una configuració molt comuna i efectiva és GCC més un IDE lleuger com ara Geany. Geany és multiplataforma (Linux i Windows), ràpid i integra funcions bàsiques com la gestió de projectes, ordres de compilació i depuració senzilla sense la sobrecàrrega dels IDE pesats.

Molts cursos llargs de C/C++ per a Linux recomanen exactament aquesta combinació: GCC com a compilador i Geany com a entorn de desenvolupament. A través d'aquests tutorials, normalment aprens el llenguatge des de zero: què és el compilador GNU i com invocar-lo, com estructurar un programa, com treballar amb condicionals, funcions, matrius, cadenes, punters, estructures, unions, E/S de fitxers i, finalment, conceptes orientats a objectes com l'herència, la sobrecàrrega d'operadors i el polimorfisme en C++.

Tot i que les opcions de l'IDE varien, els consells subjacents de la cadena d'eines solen ser consistents: utilitzeu GCC (o g++) a través de plataformes sempre que sigui possible. A Linux, aquesta és l'opció per defecte; a Windows i macOS podeu instal·lar GCC mitjançant MinGW, MSYS2, WSL, Homebrew o eines similars, mantenint un flux de treball uniforme entre sistemes i facilitant la compartició de scripts i Makefiles.

Fins i tot quan un IDE abstrau els passos de compilació, entendre que simplement està cridant gcc or g++ El treball entre bastidors és crucial per depurar problemes complexos de compilació o temps d'execució. Opcions com -g per a informació de depuració, nivells d'optimització com ara -O0, -O2 or -O3, i banderes per ajustar avisos o compliment d'estàndards (-Wall, -std=c++17, etc.) són molt importants a l'hora de diagnosticar errors subtils.

Depuració en grans bases de codi C++: des de VS Code fins a GDB natiu

Els desenvolupadors que passen del Visual Studio a Windows a Linux sovint comencen amb el codi del Visual Studio més una extensió basada en GDB i ràpidament s'adonen que l'accés al depurador pot ser dolorosament lent en backends grans. No és estrany tenir retards de 30 a 60 segons a cada pas quan es depuren sistemes de processament o lliurament de documents grans amb centenars de milers de línies i molts components de backend.

Aquesta experiència lenta no sol ser una limitació de la GDB en si, sinó de la capa d'integració o configuració entre VS Code i el depurador subjacent. Els problemes a l'extensió de depuració, com es sincronitzen els punts d'interrupció, com es carrega la informació dels símbols i com es tradueixen les ordres MI (Machine Interface) poden contribuir a alentiments massius en aplicacions complexes del món real.

Hi ha problemes coneguts de fa temps reportats a l'extensió VS Code C/C++ relacionats amb el rendiment de l'execució amb GDB a Linux. Per a alguns equips, això significa que VS Code és excel·lent com a editor, però no necessàriament l'opció més ràpida com a front-end per depurar serveis C++ monstruosos; existeixen alternatives com ara l'IDE de Google Antigravity i els IDE natius. Quan el rendiment és crític, molts enginyers recorren a l'ús directe de GDB o canvien a un IDE natiu més integrat amb la cadena d'eines local.

Així doncs, si trobeu que cada pas de la vostra sessió de depuració de VS Code a Linux triga mig minut, no doneu per fet que la depuració de Linux és inherentment tan lenta. Abans de rendir-vos, val la pena provar GDB en un terminal directament al mateix binari i comparar el comportament. Sovint, entrar a GDB és molt més ràpid, cosa que apunta a un coll d'ampolla de configuració o extensió en lloc d'un problema fonamental del sistema operatiu o del compilador.

En grans tallers de C++ a Linux, les alternatives populars per a una depuració còmoda inclouen Eclipse amb CDT (C/C++ Development Tooling), CLion, Qt Creator, KDevelop i altres IDE nadius que s'integren més estretament amb GDB i el sistema local. Aquests entorns poden proporcionar navegació de codi font, finestres de vigilància i punts d'interrupció rics mentre continuen utilitzant GDB sense la sobrecàrrega de les capes de depuració agnòstiques a l'idioma.

Informació de depuració a Linux: ELF, DWARF, debuginfo i debugsource

A Linux, els programes compilats i les biblioteques compartides s'emmagatzemen normalment en fitxers ELF (Executable and Linkable Format), i la informació de depuració associada es codifica en format DWARF. DWARF conté les metadades que els depuradors necessiten per assignar codi màquina als fitxers font, números de línia, funcions, tipus i variables.

Podeu inspeccionar les seccions DWARF en un binari ELF amb eines com ara readelf -w file, que aboca els registres de depuració en brut. Tot i que normalment no es llegeix DWARF manualment, això confirma si hi ha informació de depuració i pot ser molt valuós per diagnosticar problemes de tipus "no s'han carregat símbols" a GDB o altres eines.

Encara existeix un format de depuració més antic anomenat STABS, però es considera obsolet i es desaconsella en distribucions modernes de Linux com ara Red Hat Enterprise Linux. GCC i GDB proporcionen suport de millor esforç per a STABS, però les eines clau de l'ecosistema (per exemple, Valgrind o elfutils) poden no funcionar correctament amb ell, per això es recomana fermament DWARF.

Com que les dades de depuració solen ser grans, la majoria de distribucions les divideixen dels binaris principals en paquets separats debuginfo i debugsource. L'executable que instal·leu des del repositori per defecte normalment es desfà dels seus símbols de depuració per estalviar espai en disc i reduir l'ocupació de memòria, mentre que el paquet debuginfo corresponent conté les dades DWARF i, opcionalment, debugsource inclou les fonts coincidents.

En RHEL i sistemes similars, sol·liciteu explícitament informació de depuració en temps de compilació mitjançant -g quan creeu els vostres propis projectes amb GCC. Per a biblioteques de sistema i de tercers instal·lades des de paquets, podeu obtenir el document pertinent debuginfo i debugsource paquets de repositoris de depuració especialitzats, sovint suggerits directament per GDB quan detecta símbols que falten durant una sessió de depuració.

Instal·lació i localització de debuginfo per als binaris del sistema

Quan depureu programes en C o C++ que depenen de biblioteques de sistema, tenir debuginfo instal·lat per a aquestes biblioteques pot marcar una gran diferència en la qualitat dels backtraces i la inspecció de variables. Sense ell, només veureu adreces en brut o noms de funció alterats a les biblioteques compartides; amb ell, obteniu traces de pila amb precisió de línia i noms de variables simbòliques.

En distribucions tipus RHEL, el depurador GNU (GDB) pot detectar automàticament quan falta informació de depuració per a un objecte carregat i suggerir una ordre concreta per instal·lar el necessari. debuginfo paquet via dnf. Simplement executeu el recomanat dnf debuginfo-install ... comanda, confirmeu quan se us demani i el sistema obtindrà i instal·larà els paquets de símbols necessaris per a la vostra sessió.

Si no hi ha pistes automàtiques disponibles, podeu identificar manualment la informació de depuració necessària localitzant el fitxer binari o de biblioteca amb eines com ara locate i després consultar la base de dades RPM. L' locate comandament prové de mlocate paquet, que potser haureu d'instal·lar i inicialitzar, i un cop tingueu la ruta, podeu preguntar quin paquet el posseeix i després instal·lar la variant debuginfo corresponent.

Hi ha situacions en què no es pot determinar el paquet que ha instal·lat un binari determinat, per exemple, quan el fitxer s'ha copiat manualment o s'ha compilat in situ sense empaquetar-lo. En aquests casos, potser haureu de recórrer a fitxers de símbols personalitzats o, si és possible, reconstruir el binari vosaltres mateixos amb -g habilitat perquè GDB tingui totes les dades de depuració.

Recordeu que instal·lar debuginfo per a cada biblioteca del sistema rarament és necessari i pot ser un malbaratament. Centreu-vos en els mòduls més rellevants per al vostre problema: els binaris de l'aplicació i les biblioteques específiques on s'origina la fallada o el comportament incorrecte, en lloc d'obtenir paquets de depuració per a tot el sistema operatiu.

Ús de GDB per a la depuració interactiva a Linux

GDB és l'eina central per depurar aplicacions natives de C i C++ a Linux, exposant tant una interfície de línia d'ordres com, mitjançant integracions, front-ends gràfics com Eclipse CDT. A Red Hat Enterprise Linux, la distribució estàndard inclou la GDB completa juntament amb GUI opcionals.

Per depurar un programa des del principi, normalment s'invoca gdb ./program, configureu els punts d'interrupció segons calgui i, a continuació, inicieu l'execució dins de GDB amb el run comandament. Alternativament, podeu connectar-vos a un programa que ja s'estigui executant amb gdb -p <pid> o iniciant GDB i utilitzant el attach comanda juntament amb l'ID del procés.

Si GDB no pot inferir l'executable de destinació per a un PID determinat durant l'adjuntació, podeu indicar-li explícitament quin binari ha d'utilitzar mitjançant file comanda i després procedir a la depuració. Això és especialment útil quan es tracta de llançadors personalitzats, scripts contenidors o configuracions multibinaris on la ruta executable real no és òbvia.

Un cop connectat o iniciat, controleu el flux del programa amb ordres com ara n (següent), s (pas), until, finish i simplement c (continua), mentre tanques el depurador amb q quan estigui fet. Cadascuna d'aquestes ordres té una semàntica específica sobre si entra en els cossos de les funcions, s'executa fins a una línia determinada o reprèn l'execució fins al següent punt d'interrupció o terminació.

Per comprendre l'estat, GDB proporciona ordres d'introspecció riques per inspeccionar variables, piles de crides, registres i més, i també ofereix ajuda contextual mitjançant help info i ordres similars. Podeu mostrar la línia font actual amb list, imprimeix variables amb print, explora els marcs de pila amb backtrace i navegar per marcs amb frame, up i down.

Punts d'interrupció, punts de control i condicions a GDB

En la depuració del món real, gairebé mai no es deixa de banda a cegues main(); en comptes d'això, col·loqueu estratègicament punts d'interrupció per aturar el programa precisament on el comportament esdevé interessant. L'ordre estàndard break permet establir punts d'interrupció per número de fitxer i línia o per nom de funció, i GDB pausarà l'execució en el següent encert.

Per exemple, podeu establir un punt d'interrupció en una línia font específica utilitzant una sintaxi com ara break file.cpp:123, o interrompre al principi d'una funció amb break my_function. Quan s'arriba a la ubicació del punt d'interrupció, GDB atura el programa, cosa que permet inspeccionar les variables locals, comprovar la pila de crides i decidir si cal entrar, superar o continuar.

Els punts d'interrupció condicionals són molt valuosos quan un error només apareix després de moltes iteracions o sota valors d'entrada específics. Podeu associar una condició booleana escrita en C o C++ amb un punt d'interrupció de manera que GDB només s'aturi quan la condició s'avalua com a certa, reduint dràsticament les aturades innecessàries i fent que els bucles de depuració o les màquines d'estat complexes siguin molt més eficients.

Per supervisar els canvis en les dades en lloc del flux de codi, GDB ofereix punts de control, que s'activen quan es llegeix o s'hi escriu una expressió (sovint una variable). Amb ordres com watch, rwatch (llegir) o awatch (lectura/escriptura), podeu aturar l'execució exactament quan es modifica o s'accedeix a un determinat camp, cosa que és particularment útil per detectar canvis d'estat inesperats.

Gestioneu tots els punts d'interrupció i punts de vigilància mitjançant ordres com ara info breakpoints or info bri podeu suprimir per número o per ubicació mitjançant delete amb els arguments adequats. Això facilita mantenir un conjunt net de punts d'interrupció actius i evitar confusions en la depuració de problemes en diversos mòduls o sessions.

Depuració de processos multifil i bifurcats

La depuració de programes en C i C++ que fan un ús extensiu de fils o forques requereix una certa consciència addicional de com GDB rastreja els contextos d'execució. Per defecte, GDB designa un fil d'execució actual i la majoria d'ordres operen en aquest fil d'execució tret que canvieu explícitament mitjançant thread i l'identificador del fil.

Quan el programa es bifurca, la configuració set detach-on-fork determina si GDB segueix el fill o el pare i com gestiona el procés no seguit. Podeu configurar GDB per mantenir el control d'ambdós o per separar-se d'un costat automàticament, depenent de si el pare, el fill o tots dos són rellevants per a la vostra anàlisi.

Les versions més noves de GDB han evolucionat la manera com es numeren els fils, introduint un ID de fil inferior juntament amb un ID de fil global diferent per a la compatibilitat. La variable de conveniència $_thread i les API de Python InferiorThread.num ara reflecteixen la numeració per inferior, mentre que l'identificador global està disponible a través de $_gthread i InferiorThread.global_num, garantint que les eines més antigues basades en identificadors globals continuïn funcionant.

També s'ha millorat la gestió de senyals en la depuració multifil de treball, de manera que els senyals sempre es lliurin al fil correcte. Si canvieu de fil després que un senyal aturi el programa i després intenteu continuar, GDB pot demanar confirmació, evitant així un lliurament incorrecte accidental i fent que la depuració relacionada amb els senyals sigui més fiable.

Tot això significa que, a l'hora d'analitzar interbloquejos, curses o errors estranys activats per senyals, podeu confiar en el model de fils de GDB per rastrejar la ruta d'execució correcta amb un control precís. Combinat amb punts d'interrupció, punts de control i punts de captura, això permet una depuració robusta de diversos fils fins i tot en serveis C++ altament concurrents.

Traçament de crides al sistema i a la biblioteca: strace, ltrace i SystemTap

De vegades, la manera més ràpida d'entendre per què un programa en C o C++ es comporta malament no és repassar cada línia, sinó observar com interactua amb el sistema operatiu i les seves biblioteques compartides. Linux ofereix diverses eines potents per a això: strace, ltrace, SystemTap i fins i tot el mateix GDB a través de punts de contacte especialitzats.

L' strace la utilitat rastreja les crides del sistema: interaccions amb el nucli com ara open, read, write, mmap, execve i així successivament, juntament amb els seus paràmetres i valors de retorn. Podeu executar el vostre programa a través de strace o adjuntar-se a un procés en execució per PID, opcionalment filtrant quines crides al sistema mostrar mitjançant expressions com ara -e trace=call i controlant si cal seguir fills bifurcats o fils amb -f.

Com que les aplicacions reals emeten un gran nombre de crides al sistema, la combinació strace amb eines de shell com ara tee és comú tant veure la sortida en directe com emmagatzemar-la per a la seva anàlisi. Això us ajuda a identificar fitxers que falten, problemes de permisos, comportaments de xarxa inesperats o altres problemes a nivell de sistema operatiu que poden no ser evidents des del mateix codi.

Complementant Strace, ltrace se centra en les crides a funcions de biblioteca compartida a l'espai d'usuari, mostrant invocacions i valors de retorn per a funcions exportades des d'objectes dinàmics. A RHEL 8 hi ha una limitació coneguda on ltrace no pot rastrejar certs executables del sistema, però funciona normalment per a binaris creats per l'usuari, cosa que el converteix en una eina valuosa per entendre com el vostre programa utilitza les API de la biblioteca.

SystemTap és un marc de treball de traçat més avançat que permet controladors d'esdeveniments personalitzats tant per a esdeveniments del nucli com de l'espai d'usuari utilitzant el seu propi llenguatge de scripting. Pot ser més complex d'utilitzar que strace o ltrace, però s'escala millor i admet filtratges i agregacions sofisticats. Per comoditat, es pot utilitzar un script de mostra anomenat strace.stp inclou SystemTap per imitar un comportament similar a Strace utilitzant la infraestructura de SystemTap.

El mateix GDB pot participar en el rastreig mitjançant punts de captura per a crides al sistema i senyals, mitjançant ordres com ara catch syscall i catch signal. Això fa que el depurador aturi l'execució cada vegada que el programa realitza certes crides al sistema o rep senyals particulars, cosa que pot ser molt útil quan es necessita un control precís durant la depuració interactiva.

Abocaments de memòria i depuració post mortem amb GDB

Quan una aplicació C o C++ falla o es penja d'una manera que és difícil de reproduir interactivament, els abocaments de memòria proporcionen una instantània de la seva memòria i estat en el moment crític. Un abocament de memòria és un fitxer ELF que conté el contingut de parts de la memòria del procés (pila, heap, mapatges) en finalitzar, que podeu analitzar més tard amb GDB com si estiguéssiu connectats en el moment de la fallada.

Per utilitzar els dumps del core de manera efectiva, heu d'assegurar-vos que es generin realment i que no estiguin bloquejats pels límits de recursos o la configuració. Límits de la closca com ara ulimit -c pot impedir que es creïn fitxers bàsics; establir el límit a unlimited elimina els límits de mida, tot i que hauríeu de revisar les implicacions de l'espai en disc en els sistemes de producció.

En els sistemes RHEL moderns, systemd-coredump gestiona els dumps de memòria de manera transparent i els emmagatzema en una ubicació centralitzada semblant a un diari en lloc de sortir core fitxers dispersos per directoris. L' coredumpctl L'eina us permet llistar els errors registrats, inspeccionar les seves metadades i exportar el fitxer principal real a una ruta escollida per a una anàlisi més profunda.

Quan es crea un flux de treball sistemàtic de captura d'errors, és habitual instal·lar el sos paquet i ús sosreport per generar un fitxer tar amb la configuració del sistema i els registres. Combinat amb el fitxer principal exportat i els binaris de l'aplicació, això us proporciona tot el necessari per analitzar errors en una màquina separada o lliurar-los a un altre equip o proveïdor.

Fins i tot podeu activar deliberadament un abocament de memòria per a un procés que no respon enviant-li un senyal d'avortament o utilitzant eines com ara gcore, que aboquen la memòria del procés mentre encara s'està executant. durant una gcore dump, el procés s'atura breument i després reprèn l'execució normal, cosa que permet l'anàlisi fora de línia d'un estat problemàtic sense finalitzar completament el servei.

Trobar l'executable i els símbols adequats per a l'anàlisi del nucli

Per analitzar un abocament de memòria de manera significativa, GDB necessita tant el fitxer principal com l'executable exacte (a més de qualsevol biblioteca compartida rellevant) que l'ha produït. Això és important perquè els binaris no coincidents, creats a partir de versions diferents, poden provocar traces inverses enganyoses i dissenys de variables incorrectes.

Eines com coredumpctl info mostra metadades detallades per a cada nucli capturat, incloent-hi la ruta a l'executable principal i un ID de compilació que identifica de manera única el binari. L'ID de compilació pot semblar un hash hexadecimal llarg i el podeu comparar amb l'ID de compilació de la vostra còpia local del binari per assegurar-vos que són idèntics abans d'iniciar GDB.

Si l'executable i les seves biblioteques provenen de paquets RPM, podeu utilitzar sosreport i la base de dades de paquets per obtenir les versions exactes necessàries. En alguns casos, fins i tot podeu reinstal·lar els paquets coincidents en una màquina de depuració dedicada i després utilitzar les GDB. set sysroot configuració per apuntar-la a un disseny de biblioteca duplicat per a la depuració d'estil remot.

Un cop tingueu els objectes correctes, inicieu una sessió de GDB amb una ordre com ara gdb /path/to/exe /path/to/core i deixa que GDB carregui el nucli. Si falta informació de depuració per a algun mòdul, GDB mostrarà missatges que suggereixen quins paquets o fitxers de símbols hauríeu d'instal·lar per obtenir una visibilitat completa dels símbols.

Si els símbols de depuració de la vostra aplicació es proporcionen en fitxers separats en lloc de mitjançant paquets, podeu carregar-los explícitament mitjançant symbol-file comanda dins de GDB. No esteu obligats a tenir informació de depuració per a cada biblioteca compartida del nucli; centrar-vos en la vostra pròpia aplicació i les biblioteques sospitoses sol ser suficient per reconstruir la pila i l'estat rellevants.

Quan analitzeu un abocament de memòria, recordeu que les ordres per controlar l'execució del programa (com ara step o continue) ja no tenen sentit, perquè no hi ha cap procés en directe adjunt. En comptes d'això, us baseu en ordres d'inspecció (examinant els marcs de pila, les variables locals i globals, les regions de memòria i els fils de treball) per inferir per què es va produir la fallada o on es va quedar encallat el programa.

Escenaris avançats de buidatge de memòria i canvis de GDB en RHEL modern

Algunes aplicacions d'alta seguretat o alt rendiment marquen parts de la seva memòria com a no es poden abocar mitjançant senyaladors com ara VM_DONTDUMP, cosa que impedeix que aquesta memòria s'escrigui als fitxers principals. Això protegeix les dades sensibles (per exemple, claus criptogràfiques o registres financers) i redueix les mides de l'abocament de dades, però dificulta l'anàlisi completa fora de línia.

Si teniu una necessitat imperiosa de capturar-ho tot, incloses les àrees que normalment s'exclouen dels abocaments de memòria, podeu configurar GDB per ignorar el senyalador de no abocament de memòria i forçar un abocament de memòria complet. GDB ofereix opcions per substituir VM_DONTDUMP i abocar tota la memòria del procés en un fitxer principal per a anàlisis forenses o depuració profunda.

Pel que fa a les eines, la versió de GDB inclosa amb RHEL 8 introdueix diversos canvis de comportament i de ruptura en comparació amb RHEL 7, sobretot en àrees on la gent solia analitzar la sortida del terminal. En lloc de rastrejar la sortida textual, Red Hat recomana escriure scripts utilitzant l'API Python de GDB o el protocol Machine Interface (MI), tots dos dissenyats per al consum programàtic.

Els canvis notables inclouen el llançament de versions inferiors per part de GDBserver a través d'un shell per permetre l'expansió d'arguments, l'eliminació del suport de GCJ (Java), la sintaxi actualitzada per a les ordres de manteniment de símbols de volcat i ajustos en la gestió de sysroot per a un millor suport a la depuració remota. Algunes ordres i modes, com ara la compatibilitat amb HP-UX XDB i remotebaud, s'han retirat o substituït per equivalents més genèrics com ara set serial baud.

A més, el GDB va introduir límits com ara max-value-size per evitar l'assignació de memòria il·limitada en imprimir valors molt grans, s'ha canviat la manera com es controla la mida de l'historial d'ordres mitjançant GDBHISTSIZE en lloc de HISTSIZE, i va afegir un límit de candidats a la finalització mitjançant set max-completions. Aquestes mesures de seguretat ajuden a evitar bloquejos o un consum excessiu de memòria en depurar programes patològics o corruptes.

L'efecte net per als desenvolupadors de C i C++ a Linux és un depurador més robust i amb scripts que s'adapta a bases de codi enormes i escenaris d'error estranys, sempre que conegueu les ordres i els botons de configuració actualitzats. Combinat amb infraestructures de compilació modernes com GCC i Clang/LLVM (i ofertes com IBM Open XL C/C++ a Power), GDB forma l'eix vertebrador d'una potent cadena d'eines per desenvolupar i solucionar problemes de programari natiu complex a Linux.

Triar el compilador i l'IDE adequats, habilitar la informació de depuració de DWARF i instal·lar paquets debuginfo, i aprofitar els fluxos de treball GDB, strace, ltrace, SystemTap i core-dump us ofereix un entorn Linux C/C++ ràpid, transparent i adequat per als backends més grans, fins i tot si les vostres primeres impressions provenen d'una sessió de depuració de VS Code lenta. Amb la configuració correcta i el coneixement de les eines disponibles, la depuració a Linux no només coincideix amb la comoditat de Visual Studio a Windows; en molts escenaris, realment us ofereix un control més precís i una visibilitat més profunda de com es comporten realment les vostres aplicacions C i C++.