On 15/06/13 18:50, Bob Breuer wrote:
I'm aiming for a cpeek that catches the data faults on sparc32, so I've coded up the attached test code.
The fault handler here is almost trivially simple: set a new instruction pointer and return to it. All the magic is done in push_trap_handler and do_trap_handler, and they act similar to setjmp/longjmp. Nesting is allowed, so it should be possible to use this at the top level for printing out pretty error messages for any fault just like OBP.
I'm looking for any comments and suggestions. This proof of concept only handles mmu data faults, but is extendable. Example tests: deadbeef try-fault returns false (0), 10000 try-fault returns true (-1) and the value at 0x10000
Bob
I took a peek at the OpenBOOT source code to see what that does, and it seems that under the hood it is based on a trap handling solution. The key is newguarded-execute which on SPARC64 does the following:
* Save the current contents of traps 30, 1f, 32 and 34 0x30 = Data Access Exception 0x1f = Level 15 interrupt 0x32 = Data Access Error 0x34 = Unaligned Access Error
* Invoke the Forth word, throwing an a Forth exception upon error
* Restore the contents of the above traps
From the SPARCv8 manual we could say that these map to the following SPARC32 traps:
* 0x09 Data Access Exception * 0x1f Level 15 interrupt * 0x29 Data Access Error * 0x07 Unaligned Access Error
In terms of the routine itself, have you had a look at the work I did a while back to catch the I/D-MMU miss traps on SPARC64? In particular I added SAVE_CPU_STATE(x) and RESTORE_CPU_STATE(x) macros to arch/sparc64/vectors.S that do all of the context save/restore work so that the code required to get back into C outside of this is fairly minimal (see reload_DMMU_tlb in the same file).
ATB,
Mark.