62 / 84
EMBEDDED
MAGGIO
62
SOFTWARE
|
HYPERVISOR
per il cruscotto manda un segnale via hypervisor
al guest che gestisce il condizionamento, il quale
accenderà il riscaldamento.
Impatto dell’hypervisor sui debugger
Finora tutto bene, ma cosa succede se durante la
fase di sviluppo il sistema non si comporta come
previsto? Ad esempio se la procedura che dovreb-
be segnalare l’allarme non si attiva, o se il siste-
ma di condizionamento non capisce cosa vuole
l’automobilista? Per trovare la malfunzione è ne-
cessario esaminare il software con un debugger.
In teoria ci sono due modalità di debug: il debug-
ging “run mode” controllato a software e quello
“stop mode” controllato ad hardware.
Il metodo di debug run mode comporta il carica-
mento nel sistema di un software di debug aggiun-
tivo (ad esempio “gdbserver” per processi Linux)
che si occupa del debug effettivo.
L’avanzamento a step singoli, i bre-
akpoint ecc., sono tutti gestiti da
questa unità software, chiamata
!% + À
debugger sul computer di sviluppo
comunica con l’agent, tipicamente
via interfaccia seriale o Ethernet.
Per essere sicuri che tutto funzioni
vengono fermati solo i componenti
sotto debug, ad esempio un proces-
so Linux. Il resto del sistema con-
tinua a girare, per questo motivo
viene chiamato run mode. Il siste-
ma deve continuare a girare per
garantire che la comunicazione con
il debugger rimanga attiva.
Questo tipo di sessione di debug ha
bisogno solo di un opportuno cana-
le di comunicazione. Se al livello
più basso è presente un hypervisor,
il canale viene semplicemente ruotato attraverso
di esso (Figura 3). Non appena questo percorso è
stabilito, né il debugger né tantomeno l’agent sono
consapevoli della presenza dell’hypervisor nel
mezzo, cioè il debug avviene in modo “hypervisor
agnostic”. Questo metodo è perfetto se il sistema
deve continuare l’esecuzione durante il debug, ad
esempio per mantenere attivi dei protocolli di co-
%
À
delle funzioni di un processo o in caso di processi
all’interno di una stessa macchina. Ma questo me-
todo rivela i suoi limiti quando si entra nel merito
dei driver (moduli di Linux), specialmente quando
l’utente deve uscire dalla macchina virtuale e sono
coinvolti altri guest o l’hypervisor. Se c’è un errore
nel segnale di allarme al di fuori del processo nella
suddetta catena di eventi, si rende quindi necessa-
rio un altro metodo di debug.
Fig. 3 – Debug “run mode” con gdbserver
Fig. 4 – Debugger JTAG con sistema target. Questo è il modo in cui un
debugger hardware si collega a un sistema target