GNU GDB 18.1 è disponibile. La nuova versione dello storico debugger del progetto GNU introduce importanti miglioramenti su Windows, nuovi strumenti per analizzare programmi e processi, estende le API Python e aggiunge il supporto a nuove piattaforme. Ma il rilascio offre soprattutto l'occasione per raccontare uno degli strumenti fondamentali e meno conosciuti attraverso i quali viene costruito il software che utilizziamo ogni giorno.
Quando un programma smette di funzionare, produce un risultato sbagliato o si blocca apparentemente senza motivo, sapere che esiste un errore è soltanto l'inizio del problema.
Bisogna capire dove si trova.
Ed è qui che entra in gioco un debugger.
GNU GDB permette allo sviluppatore di eseguire un programma sotto osservazione, interromperlo in un punto preciso, avanzare istruzione dopo istruzione, esaminare variabili e memoria, seguire thread, analizzare un crash e cercare di ricostruire ciò che il programma stava realmente facendo nel momento in cui qualcosa è andato storto.
È, in un certo senso, uno strumento che permette di fermare il tempo all'interno di un programma.
Possiamo impostare un breakpoint su una determinata funzione, avviare l'applicazione e lasciare che GDB la esegua normalmente fino a quel punto. Quando l'esecuzione raggiunge il breakpoint viene sospesa e possiamo osservare lo stato interno del processo.
Da lì possiamo procedere una riga alla volta.
Possiamo chiedere il valore di una variabile.
Possiamo osservare lo stack delle chiamate e scoprire attraverso quali funzioni siamo arrivati fino a quel punto.
Possiamo esaminare registri e memoria.
E possiamo provare a capire perché ciò che il programmatore pensava sarebbe accaduto non corrisponde a ciò che la macchina ha realmente fatto.
Questa capacità ha reso GDB uno degli strumenti fondamentali dello sviluppo su sistemi GNU/Linux e Unix, ma il programma non è limitato a una singola piattaforma o a un solo linguaggio.
GDB può eseguire il debug a livello sorgente di programmi scritti in C, C++, Ada, Fortran, Go, Rust e diversi altri linguaggi, e può lavorare con più di una dozzina di architetture di processore.
La versione 18.1 amplia ulteriormente queste possibilità.
Una parte considerevole del lavoro riguarda questa volta Windows.
Il target nativo Windows supporta ora la modalità non-stop, che permette di fermare alcuni thread mentre altri continuano l'esecuzione. Funziona inoltre scheduler-locking, viene aggiunto il supporto nativo alle variabili Thread Local Storage e migliora l'integrazione con Windows Terminal.
Quando viene utilizzato UTF-8, GDB può ora sfruttare colori reali a 24 bit e gestire correttamente testo UTF-8 ed emoji. Anche la rappresentazione dei percorsi viene resa più coerente, utilizzando sistematicamente le barre / invece di mescolare i due stili tipici dei percorsi Windows.
Potrebbero sembrare dettagli marginali, ma mostrano una caratteristica importante del Software Libero.
Un programma nato nell'universo GNU e storicamente associato soprattutto a Unix e GNU/Linux non è necessariamente costretto a rimanere confinato lì.
Software Libero non significa software per un unico sistema operativo.
Il codice può essere portato, adattato e migliorato anche per piattaforme proprietarie, permettendo a chi le utilizza di scegliere strumenti liberi almeno per una parte del proprio lavoro.
GDB 18.1 introduce inoltre un nuovo comando di aiuto chiamato essential, pensato per mostrare un insieme minimo di comandi utili a chi si avvicina per la prima volta al debugger.
È una piccola novità che affronta un problema reale.
GDB è estremamente potente, ma proprio questa potenza può renderlo inizialmente intimidatorio. Chi lo avvia per la prima volta si trova davanti a uno strumento costruito nel corso di decenni e dotato di una quantità enorme di comandi e possibilità.
Indicare un percorso essenziale significa riconoscere che la disponibilità del codice non basta a rendere accessibile uno strumento.
Servono documentazione, interfacce comprensibili e percorsi attraverso i quali una nuova persona possa imparare a utilizzarlo.
Tra i nuovi comandi troviamo anche save history, che consente di salvare su file la cronologia dei comandi eseguiti, insieme a strumenti per salvare gli skip e i comandi definiti dall'utente.
Su Linux arriva inoltre info proc environ, che permette di visualizzare le variabili d'ambiente iniziali di un processo.
Migliora anche la gestione delle variabili locali.
info locals può ora indicare quando una variabile ne nasconde un'altra con lo stesso nome e mostrare informazioni sulla loro posizione. È un aiuto particolarmente utile per comprendere situazioni nelle quali variabili definite in ambiti differenti possono facilmente generare confusione durante il debug.
La nuova versione aggiunge poi il supporto per nuovi target, tra cui GNU/Linux su MicroBlaze attraverso gdbserver e AArch64 MinGW, ampliando ulteriormente le piattaforme sulle quali lo strumento può essere utilizzato.
Un'altra parte importante riguarda Python.
GDB non è infatti soltanto un programma interattivo utilizzato digitando comandi nel terminale. Dispone di API attraverso le quali può essere esteso e integrato con altri strumenti.
La 18.1 introduce nuove classi per lavorare con i core file, nuovi eventi, strumenti per personalizzare gli stili, accesso alle righe sorgenti associate alle tabelle dei simboli e ulteriori possibilità per analizzare il disassemblato.
Questo rende possibile costruire sopra GDB interfacce, strumenti di analisi e automazioni specializzate.
È uno degli aspetti più interessanti dell'architettura del Software Libero: uno strumento può diventare infrastruttura per costruire altri strumenti.
GDB 18.1 continua anche il lavoro sul Debugger Adapter Protocol, il protocollo attraverso il quale debugger differenti possono comunicare con editor e ambienti di sviluppo utilizzando un'interfaccia comune.
Questo significa che l'utente non deve necessariamente lavorare direttamente all'interno del terminale di GDB.
Un IDE può fornire pulsanti, pannelli grafici, breakpoint e visualizzazioni delle variabili utilizzando GDB come motore sottostante.
Ancora una volta compare un principio fondamentale: separare lo strumento dall'interfaccia attraverso standard e protocolli che permettano a componenti differenti di collaborare.
Ma una nuova versione significa anche abbandonare progressivamente tecnologie che hanno concluso il proprio ciclo di vita.
GDB 18.1 elimina il supporto ai vecchi formati di debug stabs e mdebug, al formato binario dbx e al Common Trace Format; non supporta più le vecchie sezioni .gdb_index precedenti alla versione 7 e abbandona DWP versione 1.
AIX 7.1 non è più supportato e il target s390 a 32 bit viene deprecato in vista di una futura rimozione, mentre s390x a 64 bit continua a essere supportato.
Sono decisioni inevitabili per un progetto che attraversa generazioni differenti dell'informatica.
Mantenere indefinitamente ogni formato, piattaforma e comportamento storico ha un costo. Ogni vecchia funzione aumenta la quantità di codice da verificare e può rendere più difficile modificare l'architettura interna.
La compatibilità è importante, ma non può trasformarsi nell'impossibilità di evolvere.
Ed è proprio la storia di GDB a rendere interessante questo equilibrio.
Il progetto risale agli anni Ottanta ed è stato uno degli strumenti fondamentali dell'ambiente di sviluppo GNU.
Eppure nel 2026 continua a essere aggiornato per lavorare con Rust, Python, protocolli moderni per gli IDE, nuove architetture e persino Windows Terminal.
È difficile trovare un esempio migliore di ciò che significa mantenere Software Libero nel lungo periodo.
Il codice aperto, da solo, non garantisce che un programma sopravviva.
Un repository può essere pubblico e contemporaneamente abbandonato.
Ciò che mantiene vivo un progetto sono le persone che continuano a correggerlo, adattarlo ai nuovi sistemi, rimuovere ciò che non serve più, documentarlo e renderlo utilizzabile dalla generazione successiva di sviluppatori.
GDB rappresenta anche qualcosa di ancora più importante: la possibilità di osservare il software dall'interno.
Quando utilizziamo un programma proprietario siamo normalmente autorizzati a vedere ciò che l'interfaccia decide di mostrarci.
Con il Software Libero possiamo leggere il codice sorgente.
Con un debugger possiamo fare un ulteriore passo: possiamo osservare quel codice mentre viene eseguito dalla macchina.
Possiamo fermarlo.
Possiamo esaminarne la memoria.
Possiamo seguirne il comportamento.
Possiamo confrontare ciò che è stato scritto con ciò che realmente accade.
Non è una libertà che interessa soltanto i programmatori.
Gli stessi strumenti vengono utilizzati per analizzare crash, studiare vulnerabilità, comprendere sistemi complessi e verificare il comportamento del software dal quale dipendono infrastrutture e servizi.
La trasparenza del software non consiste soltanto nella possibilità di leggere il codice. Consiste anche nel possedere gli strumenti necessari per studiare ciò che quel codice fa quando diventa un processo reale.
GNU GDB 18.1 continua a offrire proprio questo.
Non è probabilmente il programma che mostreremo a qualcuno per convincerlo a provare GNU/Linux.
Non ha bisogno di esserlo.
È uno di quegli strumenti che lavorano dietro le quinte e rendono possibile costruire, correggere e comprendere molti dei programmi che invece utilizziamo ogni giorno.
Ed è forse proprio questa la sua importanza.
Il Software Libero ci permette di aprire il codice. GDB ci permette di entrarci dentro mentre sta funzionando.