"Sessione di Debugging e Modello di Esecuzione"

Il motore del debugger può eseguire il debug di più destinazioni contemporaneamente. Una sessione di debug inizia quando il motore acquisisce un obiettivo e continua finché tutti gli obiettivi non vengono eliminati. 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 gli obiettivi mentre la sessione è accessibile.

Il ciclo principale di un debugger consiste in genere nell'impostare lo 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 risulta accessibile. Il motore invia quindi una notifica ai callback dell'evento e segue le regole di filtro eventi. I callback degli eventi e i filtri degli eventi determinano il modo in cui l'esecuzione nella destinazione deve continuare. 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 del target nel modo determinato dai callback degli eventi e dai filtri eventi, e la sessione diventa nuovamente inaccessibile.

Per la durata della chiamata WaitForEvent , in particolare, durante la notifica dei callback dell'evento e l'elaborazione delle regole di filtro, il motore si trova in uno stato denominato "all'interno di un'attesa". Mentre 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. È possibile impostare lo stato di esecuzione usando il metodo SetExecutionStatus o eseguendo un comando del 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 dell'estensione.