Perché l'accesso a una posizione non mappata non genera un'eccezione hardware (Microblaze)

Question

Voglio scrivere il mio codice che gestirà le mancanze TLB sul Microblaze e attraverso ciò, ovviamente, le tabelle della pagina ecc. Tutto questo viene fatto su OVPsim.

Come sto imparando come vado ho scritto questo piccolo pezzo di assemblaggio per fare riferimento a una posizione non mappata (0x1000000) - Sto facendo funzionare questo codice come privilegiato con VM on:

ori r20, r0, 0 
ori r12, r0, 0x1000000 
/* next line should break it */ 
sw r20, r12, r0 

(Vale a dire, scrivere il contenuto di r20 == 0 fuori all'indirizzo formate da ORing r12 == 0x1000000 e r0 == 0 => 0x1000000 ovviamente)

Ma invece di saltare al vettore eccezione, GDB rapporti "Programma ricevuto SIGSEV" -. quello che ho ottenuto sbagliato? Non ho il bit dell'eccezione dell'abilitazione abilitata nel MSR ma il manuale dice che non è possibile mascherare queste eccezioni in ogni caso in modo che non dovrebbe essere il problema.

Ulteriori informazioni non riesco a ottenere qualsiasi (per esempio, tra le eccezioni di disallineamento) del codice di gestione delle eccezioni di eseguire, (a meno che esplicitamente lo chiamo), anche se non sto usando il debugger. Con il debugger off ottengo questo output da OVPsim (NB Ho semplicemente cambiato l'indirizzo di prova - non v'è alcun significato nella differenza tra 0xA000000 e 0x100000 sopra):

Processor Exception (PC_PRX) Processor 'platform/cpu0' 0x248: sw  r20, r12, r0 
Processor Exception (PC_WPX) No write access at 0xa000000 

Questo è tutto il codice viene eseguito in modalità privilegiata, quindi non vedo alcuna ragione esplicita per non chiamare i gestori, a meno che non sia stato impostato Non ho configurato correttamente Microblaze. Ho questi acceso:

icmAddStringAttr(cpu1_attr, "endian", "big"); 
icmAddDoubleAttr(cpu1_attr, "mips", 100.000000); 
icmAddStringAttr(cpu1_attr, "variant", "V8_20"); 
icmAddBoolAttr(cpu1_attr, "verbose", "true"); 
icmAddUns32Attr(cpu1_attr, "C_PVR", 2); 
icmAddUns32Attr(cpu1_attr, "C_USE_MMU", 3); 
icmAddStringAttr(cpu1_attr, "C_USE_BARREL", "1"); 
icmAddStringAttr(cpu1_attr, "C_USE_DIV", "1"); 
icmAddUns32Attr(cpu1_attr, "C_USE_INTERRUPT", 1); 
icmAddUns32Attr(cpu1_attr, "C_MMU_TLB_ACCESS", 3); 
icmAddUns32Attr(cpu1_attr, "C_UNALIGNED_EXCEPTIONS", 1); 
icmAddUns32Attr(cpu1_attr, "C_ILL_OPCODE_EXCEPTION", 1); 
icmAddUns32Attr(cpu1_attr, "C_DIV_ZERO_EXCEPTION", 1); 
icmAddUns32Attr(cpu1_attr, "C_OPCODE_0x0_ILLEGAL", 1); 
icmAddUns32Attr(cpu1_attr, "C_DEBUG_ENABLED", 1); 

Non c'è ragione di credere che questo non funzionerà come OVPsim verrà eseguito Linux sul Microblaze.

Answer 1

Grazie a Jamie Garside del gruppo Real-Time Systems della York University: l'impostazione predefinita del simulatore OVP è di intercettare le eccezioni e di uscire dalla simulazione, ecco perché nessuna sorta di eccezione veniva eseguita nel modo che mi aspettavo - invece venivano semplicemente segnalati come una sorta di errore e la simulazione veniva interrotta.

Tuttavia, se ICM_ATTR_SIMEX è definito per la simulazione, la simulazione eseguirà i gestori di eccezioni proprio come farebbe il processore reale, quindi aggiungendo ICM_ATTR_SIMEX agli attributi della mia istanza, ad esempio, eseguendo l'OR come mostrato di seguito, si mette tutto nel suo giusto posto:

#define SIM_ATTRS (ICM_ATTR_DEFAULT|ICM_ATTR_SIMEX) 

Answer 2

L'eccezione TLB viene generata, è GDB che ti impedisce di accedere al gestore.

Il debug della modalità VM è complicato. Io non sono a conoscenza di OVPsim e come ben si è integrato con GDB, ma ci sono diversi modi di lavorare il vostro senso attraverso di essa:

1. software esplicita breakpoint. Basta usare l'istruzione brk r16, 0x18 in cui si desidera impostare un punto di interruzione nel codice e lasciare GDB andare con il comando continue. Si fermerà una volta eseguita questa interruzione, indipendentemente dal suo codice utente VM o dal gestore di eccezioni.

   Lo svantaggio di questo, non c'è un modo semplice per continuare da GDB, una volta raggiunto questo tipo di interruzione. Dovresti modificare r16 al successivo indirizzo di istruzioni o sostituire l'istruzione brk con nop da GDB.

2. Punto di interruzione hardware. Questa è l'interruzione più semplice da utilizzare per eseguire il debug di entrambe le eccezioni e del codice lato VM senza preoccuparsi della presenza della pagina TLB. Ma i breakpoint hardware richiedono il supporto hardware di Microblaze (non sono sicuro che OSPsim li supporti). Per utilizzarlo in GDB, utilizzare semplicemente hbreak (o hb) anziché il comando break.

3. GDB soft-breakpoints.Potresti ancora riuscire a utilizzare i punti di interruzione GDB di stile regolari se sai come funzionano e il tuo modello di VM è abbastanza semplice. Fondamentalmente GDB richiede l'accesso in scrittura alla tabella codici in cui si desidera interrompere (per scrivere l'istruzione brk). Pertanto, in modalità VM è necessario assicurarsi che la pagina sia presente in TLB e disponga dell'accesso in scrittura.

   È ancora più complicato impostare l'interruzione dalla modalità non VM in codice VM quando l'indirizzo virtuale è diverso da quello fisico. Dovresti essere sicuro che la pagina in cui vuoi inserire il tuo breakpoint sia caricata nella memoria fisica e tradurre manualmente l'indirizzo virtuale in fisico e impostare il punto di interruzione. Quindi, a meno che tu non abbia la mappatura 1: 1 (e tutto il codice e i dati siano all'interno della memoria) o tu abbia scritto il tuo GDB stub, è un colore usare i breakpoint GDB.

Sfortunatamente, passare attraverso il codice in GDB è quasi come utilizzare sempre i breakpoint GDB. Cioè stai andando bene all'interno del codice non-VM, o all'interno di una singola VM-page con permessi di scrittura. Ma una volta che hai bisogno di occuparti di qualcosa al di fuori di TLB o di accedere al codice VM da non VM, può diventare davvero frustrante.