Modifica e continua su GDB

Question

So che l'E&C è un argomento controverso e alcuni dicono che incoraggia un approccio sbagliato al debug, ma comunque - penso che possiamo essere d'accordo sul fatto che ci sono numerosi casi in cui è chiaramente utile - sperimentare valori diversi di alcune costanti, ridisegnare i parametri della GUI al volo per trovare una buona occhiata...Lo dici tu.

La mia domanda è: Avremo mai E&C su GDB? Capisco che si tratta di una funzionalità specifica della piattaforma e richiede una seria collaborazione con il compilatore, il debugger e il sistema operativo (MSVC ha questo semplice poiché il compilatore e il debugger sono sempre forniti in un unico pacchetto), Ma...Dovrebbe essere ancora fattibile.Ho anche sentito qualcosa sul fatto che Apple lo abbia implementato nella loro versione di GCC ^{[citazione necessaria]}.E direi che è effettivamente fattibile.

Conoscendo tutto il clamore sull'E&C di MSVC (la mia esperienza dice che è la prima cosa menzionata dagli utenti di MSVC quando richiesto "perché non passare a Eclipse e gcc/gdb"), sono seriamente sorpreso che dopo diversi anni GCC/GDB non disponga ancora di tale funzionalità.Ci sono delle buone ragioni per questo?Qualcuno ci sta lavorando mentre parliamo?

Answer 1

Si tratta di una quantità sorprendentemente non banale di lavoro, che comprende molte decisioni di design e funzionalità compromessi. Pensate: il debug. Il debugee è sospeso. La sua immagine nella memoria contiene il codice oggetto della sorgente, e la disposizione binaria di oggetti, mucchio, le pile. Il debugger sta controllando la sua immagine memoria. Ha caricato le informazioni di debug sui simboli, tipi, mapping degli indirizzi, pc (ip) a corrispondenze di origine. Esso mostra lo stack di chiamate, i valori dei dati.

Ora si desidera consentire un particolare insieme di possibili modifiche al codice e / o di dati, senza fermare il debug e il riavvio. La più semplice potrebbe essere quella di cambiare una riga di codice a un altro. Forse ricompilare il file o solo quella funzione o solo quella linea. Ora dovete patchare l'immagine del debug di eseguire quella nuova riga di codice la prossima volta che passo su di esso o comunque correre attraverso di essa. Come funziona sotto il cofano? Cosa succede se il codice è più grande della riga di codice che ha sostituito? Come lo fa interagire con le ottimizzazioni del compilatore? Forse si può fare solo su un particolare bersaglio compilato per il debug EnC. Forse si vincolare i possibili siti è legale EnC. Prendere in considerazione: cosa succede se si modifica una riga di codice in una funzione sospesa verso il basso nello stack di chiamate. Quando il codice ritorna là Si trasmette la versione originale della funzione o la versione con la linea cambiato? Se la versione originale, da dove viene quella fonte viene?

gente del posto

Si può aggiungere o rimuovere? Che cosa fare per la chiamata pila di telai sospesi? Della funzione corrente?

Si può cambiare le firme di funzione? Aggiungere campi ai campi / Rimuovi dagli oggetti? Che cosa circa le istanze esistenti? Che dire di distruttori o finalizzatori in attesa? Ecc.

Ci sono molti, molti dettagli di funzionalità di cui occuparsi a fare qualsiasi tipo di lavoro EnC usuable. Poi ci sono molti problemi di integrazione cross-strumenti necessari per fornire l'infrastruttura al potere EnC. In particolare, aiuta ad avere una sorta di archivio di informazioni di debug che possono mettere a disposizione il pre e post-edit informazioni di debug e il codice oggetto per il debugger. Per C ++, le informazioni di debug in modo incrementale aggiornabile in PDBs aiuta. collegamento incrementale può aiutare anche.

Guardando dal ms ecosistema sopra nell'ecosistema GCC, è facile immaginare i problemi di complessità e integrazione tra GDB / GCC / binutils, la miriade di obiettivi, alcuni Enc specifiche astrazioni bersaglio necessari, e il "bello avere, ma inessenziale la natura" di ENC, sono il motivo per cui non è ancora apparso in GDB / GCC.

Felice l'hacking!

(ps È istruttivo e stimolante per guardare a ciò che l'ambiente di programmazione interattivo Smalltalk-80 potrebbe fare in ST80 non esisteva il concetto di "restart" -. L'immagine e la sua memoria oggetto erano sempre in diretta, se si è modificato qualsiasi aspetto di una classe che si aveva ancora di continuare a correre. In tali ambienti oggetto delle versioni non era un ipotetico.)

Answer 2

Non ho familiarità con E&C di MSVC, ma GDB ha alcune delle cose che hai menzionato:

http://sourceware.org/gdb/current/onlinedocs/gdb/Altering.html#Altering

17.Alterazione dell'esecuzione

Una volta che pensi di aver trovato un errore nel tuo programma, potresti voler scoprire con certezza se la correzione dell'errore apparente porterebbe a risultati corretti nel resto dell'esecuzione.Puoi trovare la risposta sperimentando, utilizzando le funzionalità di gdb per alterare l'esecuzione del programma.

Ad esempio, puoi memorizzare nuovi valori in variabili o posizioni di memoria, dare un segnale al tuo programma, riavviarlo da un indirizzo diverso o persino tornare prematuramente da una funzione.

Incarico:Assegnazione alle variabili
Saltando:Proseguimento ad altro indirizzo
Segnalazione:Dai un segnale al tuo programma
Ritorno:Ritorno da una funzione
Chiamando:Chiamare le funzioni del tuo programma
Patch:Patchare il tuo programma
Compilazione e inserimento del codice:Compilazione e inserimento del codice in GDB

Answer 3

Questo è un buon riferimento alla vecchia implementazione di Apple di "fix e continua". Si fa riferimento anche altre implementazioni di lavoro.

http://sources.redhat.com/ml/gdb/ 2003-06 / msg00500.html

Ecco un frammento:

  

Fix e continuare è una caratteristica implementata da molti altri debugger,   che abbiamo aggiunto alla nostra gdb per questa versione. Sun Workshop, SGI PRODEV   WorkShop, Visual Studio di Microsoft, wdb di HP, e Hotspot Java di Sun   VM tutto fornire questa funzione in un modo o nell'altro. Ho basato la nostra   attuazione sul Fix HP WDB e continua caratteristica, che hanno   aggiunto qualche anno fa. Anche se la mia implementazione finale segue la   linee generali dell'approccio hanno preso, non c'è quasi condivise   codice tra loro. Alcune di queste è a causa della architettonica   differenze (sia il processore e l'ABI), ma anche più di esso è   a causa delle differenze di progettazione di implementazione.

Si noti che questa capacità può essere stato rimosso in una versione successiva del loro toolchain.

UPDATE: Dec-21-2012 C'è un href="http://gcc.gnu.org/wiki/cauldron2012?action=AttachFile&do=get&target=jkratoch.pdf" rel="nofollow"> GDB Roadmap presentazione GNU Tools Calderone 2012 .