64 / 84
EMBEDDED
MAGGIO
64
SOFTWARE
|
HYPERVISOR
À
le CPU virtuali e le impostazioni MMU associate.
L’awareness utilizza le informazioni simboliche di
debug dell’hypervisor (ELF/DWARF) per leggere
le necessarie informazioni dal sistema. Una vista
delle macchine virtuali con le loro risorse permette
di ottenere una rappresentazione eccellente del si-
stema (Figura 5). L’hypervisor awareness si occupa
anche di gestire la struttura delle traslazioni MMU
di livello 2, così che il debugger possa accedere a
tutte le macchine virtuali.
Per poter analizzare il contenuto di un sistema
operativo guest è necessaria una OS awareness,
ed ogni guest ne richiede una propria. Anche que-
'
À
ciascun OS qui utilizzato. Con questa awareness
si determinano i processi del sistema operativo
e le impostazioni MMU all’interno della macchi-
na virtuale, come pure la struttura delle tabelle
771 "
6# / À
-
ness utilizza le informazioni simboliche di debug
che appartengono al corrispondente sistema ope-
rativo, per esempio “vmlinux” quando si usa Li-
nux. In questo modo possono essere visualizzati
processi, thread ed altre risorse. Grazie a queste
awareness, in ultima analisi il debugger
ha una conoscenza delle macchine, dei
sistemi operativi e dei processi che gira-
no nel sistema target. Così il debugger
TRACE32 sviluppato da Lauterbach è
in grado di visualizzare una struttura
gerarchica ad albero dell’intero sistema.
Su una certa macchina o su un certo pro-
À
À
/
vedere contemporaneamente un proces-
so che opera su una macchina Linux e
un task eseguito su un dispositivo con
FreeRTOS (Figura 6). La gestione dei
!J/+DC= '
À
opportunamente in modo che lo svilup-
patore possa assegnare i simboli cari-
cati a una certa macchina o a un certo
processo. È stata anche estesa con un
À
"
2#
e uno di processo (process ID) per far sì
che il progettista possa anche accedere
sempre a qualunque indirizzo virtuale.
In questo modo nessun indirizzo virtuale
risulta ambiguo. Se il software passa per
un breakpoint l’intero sistema verrà fer-
mato come sopra descritto. Poi il debugger com-
muta automaticamente sul core (reale) e mostra
la macchina e il processo su cui il breakpoint è
scattato. Ciò permette all’utente di vedere im-
mediatamente le condizioni che hanno portato a
questo break. La macchina virtuale in cui tutto
questo è avvenuto viene detta “macchina corren-
te”, ma naturalmente è possibile cambiare la vi-
sta in modo manuale verso gli altri core con le
loro “macchine correnti”.
Accesso a sistemi guest inattivi
Con un approccio come questo l’utente non solo
può cambiare vista verso altri core hardware, ma
può anche passare ad altri sistemi guest al mo-
mento inattivi. È quindi sempre possibile accedere
ai simboli di tutte le funzioni e le variabili di altre
macchine. Le informazioni simboliche erano state
À
traduce gli indirizzi virtuali dei simboli in indiriz-
À "
771 5#
per esempio, va a leggere il valore di una varia-
J/7 À 2
'
importante che lo stato della CPU non venga mai
Fig. 6 – Una rappresentazione ad albero mostra la struttura
del sistema target