Data Abort Handler (changes)

Showing changes from revision #0 to #1: Added | Removed | Changed

OS SWI Calls

» OS_ChangeEnvironment

» Data Abort Handler

Data Abort Handler

The data abort handler is entered in the following state:

• The processor will be in ABT32 mode, with IRQs disabled
• FIQ state will match that at the time of the exception
• R14 & SPSR_und will contain the exception address and saved PSR, corresponding to when the exception was raised by the CPU. R14 will be pointing two instructions (i.e. 8 bytes) after the instruction that caused the exception.
• The other core registers will be as per when the exception was raised by the CPU. However if your code examines the registers it must take care to use the correct register bank (e.g. if the exception was from user mode, it should look at R14_usr, not R14_abt).
• R13 will be a valid stack pointer
• CP15 registers relating to exception processing will be in the correct state corresponding to that exception

If the handler is capable of handling the exception (e.g. by emulating the memory access) then it can resume execution by performing a suitable exception return operation.

Notes

On 26bit OS versions, the CPU will be in SVC26 mode, with R14 containing the combined LR+PSR.

The kernel’s default handler will save a copy of the ARM integer registers (corresponding to the CPU mode the exception occurred in) to the Exception Registers Block, reset the stack pointers for all the privileged CPU modes, and then call OS_GenerateError to report a Data Abort error.

Since abort environment handlers are called before the abort recovery code that exists in the kernel’s default environment handler, custom environment handlers should be very careful in how they operate, especially when it comes to calling external code (e.g. SWIs). For example, if the abort was caused by a supervisor stack overflow, calling a SWI from within your abort handler would result in a terminal abort loop.

See also

• OS_ChangeEnvironment