Debug di un modello di sessione ed esecuzione

Il motore del debugger può eseguire il debug di più destinazioni contemporaneamente. Una sessione di debug inizia quando il motore acquisisce una destinazione e continua fino a quando non vengono eliminate tutte le destinazioni. Una sessione di debug è inaccessibile mentre le destinazioni sono in esecuzione e accessibili quando la destinazione corrente viene sospesa. Il motore può essere usato solo per esaminare e modificare le destinazioni mentre la sessione è accessibile.

Il ciclo principale di un debugger è in genere costituito dall'impostazione dello stato di esecuzione, chiamando il metodo WaitForEvent e gestendo gli eventi generati. Quando viene chiamato WaitForEvent , la sessione diventa inaccessibile.

Quando si verifica un evento in una destinazione, il motore sospende tutte le destinazioni e la sessione diventa accessibile. Il motore invia quindi una notifica ai callback dell'evento e segue le regole del filtro eventi. I callback degli eventi e i filtri degli eventi determinano la modalità di esecuzione nella destinazione. Se determinano che il motore deve entrare nel debugger, il metodo WaitForEvent restituisce e la sessione rimane accessibile; in caso contrario, il motore riprenderà l'esecuzione della destinazione nel modo determinato dai callback dell'evento e dai filtri eventi e la sessione diventa nuovamente inaccessibile.

Per la durata della chiamata WaitForEvent , in particolare, durante la notifica dei callback degli eventi e l'elaborazione delle regole di filtro, il motore è in uno stato denominato "all'interno di un'attesa". Anche se in questo stato , WaitForEvent non può essere chiamato (non è reentrant).

Sono necessari due passaggi per avviare l'esecuzione in una destinazione: impostare lo stato di esecuzione e quindi chiamare WaitForEvent. Lo stato di esecuzione può essere impostato usando il metodo SetExecutionStatus o eseguendo un comando debugger che imposta lo stato di esecuzione, ad esempio g(Go) e p (passaggio).

Se una sequenza di comandi del debugger viene eseguita insieme, ad esempio "g ; ? @$ip": si verificherà un'attesa implicita dopo qualsiasi comando che richiede l'esecuzione nella destinazione se tale comando non è l'ultimo comando nella sequenza. Un'attesa implicita non può verificarsi quando il motore del debugger si trova nello stato "all'interno di un'attesa"; in questo caso, l'esecuzione dei comandi verrà arrestata e il comando corrente, ovvero quello che ha tentato di causare l'attesa implicita, verrà interpretato come un'indicazione della modalità di esecuzione nella destinazione. Il resto dei comandi verrà eliminato.

Nota Quando si determina se la sessione è accessibile o inaccessibile, l'esecuzione limitata di una destinazione (ad esempio, l'esecuzione di istruzioni) viene considerata eseguita dal motore. Al termine dell'esecuzione limitata, la sessione diventa accessibile.

Motore host

Quando si esegue il debug in remoto, è possibile usare più istanze del motore del debugger. Esattamente una di queste istanze gestisce la sessione di debug; questa istanza è denominata motore host.

Tutte le operazioni del debugger sono relative al motore host, ad esempio il caricamento dei simboli e il caricamento delle estensioni.