Framework di debug per linguaggio specifico del dominio

Questa è una risposta indiretta alla tua domanda. Nel 1982 scrissi il primo debugger C a livello di sorgente, CDB (forse anche il primo debugger remoto, debugger del kernel e debugger multi-processo / multi-thread). Inizialmente l'ho scritto perché I era necessario (l'unica altra opzione era sdb su un VAX, tranne che non avevo un VAX e sdb pianeti succhiati). Questa situazione era in perfetta armonia con La Cattedrale e il Bazar < La prima regola di / a>: ogni buon lavoro del software inizia a graffiare il prurito personale di uno sviluppatore.

Poiché tu sei la persona con il prurito, sei anche molto probabilmente la persona migliore per intraprendere questo viaggio.

Per creare un debugger a livello di origine sono necessari i seguenti elementi:

1. Un modo di iniziare e amp; fermare l'esecuzione senza uccidere il processo di destinazione. Dato il tuo ambiente questo potrebbe essere banale o potrebbe essere un affare killer. ptrace(2) era la chiave in UN * X-land.
2. Un modo per interrogare lo stato corrente di esecuzione del processo di destinazione. Ad esempio Program Counter (PC) (o equivalente), Stack Pointer (SP), registri e memoria dati / istruzioni. Come il primo, banale o affare killer.
3. Un modo di mappare il PC = > file: line e vice versa-file: line = > PC. Questo è fondamentale perché è ciò che distingue un debugger a livello di origine da un debugger a livello di assembly (o qualsiasi altro equivalente nel tuo mondo). Le lingue compilate spesso generano simboli aggiuntivi nel file .o che rende possibile questa mappatura (anche se non sempre in modo semplice).
4. Un modo per inserire e rimuovere un punto di interruzione . Il modo in cui questo viene realizzato può variare notevolmente tra gli ambienti. Deve essere fatto in modo tale da essere il più possibile non-disruptive dello stato di esecuzione in modo da poter evitare l'equivalente debugger del principio di indeterminazione di Heisenberg-cioè. il bug reagisce in modo diverso a seconda di dove si imposta la pausa. Nota: non puoi evitarlo con bug relativi ai tempi.

Una volta che queste cose sono state bloccate, la tua vera elaborazione dei comandi dovrebbe essere piuttosto semplice. Ad esempio, quando si preme un punto di interruzione, si legge il PC, lo si associa al file: riga e si visualizza quella linea (normalmente con +/- 5 linee di contesto). Per una traccia stack, ottieni l'SP e stampa ogni frame utilizzando le informazioni sui simboli aggiuntivi che forniscono l'offset della variabile locale da SP, ecc. Ecc.

Quali comandi hanno senso saranno guidati da come tu (e i tuoi futuri utenti) pensi quando usi la lingua. Le cose che hanno senso per una lingua sono assurdità se applicate a un'altra lingua. Ad esempio, data la dichiarazione C struct FOO *pfoo; , è bello se digitando *pfoo al prompt dei comandi si ottiene un dump formattato della struttura puntata. Questo potrebbe non avere senso quando si esegue il debug di qualcosa come SQL, ma ci sono spesso analoghi.

Il diavolo è nei dettagli di questi 4 articoli, quindi fammi sapere se desideri ulteriore assistenza offline. La mia email è nel mio profilo.

Non è al 100% quello che stai cercando, ma puoi dare un'occhiata a Xtext e questo filo "http://www.eclipse.org/forums/index.php/mv/tree/163373/#page_top">. Ma ovviamente questo potrebbe non aiutarti se il tuo DSL interno non è basato su Xtext ...