h6. [[Programmer's Reference Manuals]] h6(. » [[Vectors]] h6((. » [[Software Vector Numbers]] h6(((. » SeriousErrorV h2. SeriousError Vector (45) |_<^{width:3em}. Entry |<^. | |<^. R2|<^. Reason code| |<^. - |<^. Other registers dependent on reason code| |_<^{width:3em}. Exit |<^. | |<^. - |<^. All registers preserved| h4. Use This vector is called during serious error reporting and recovery, such as an Abort. It should not be claimed, but called to notify relevant sections of the OS that a serious error has occurred and/or recovery steps have been taken. Note that handlers of SeriousErrorV have tighter restrictions placed on them than with other vectors. Specifically, reason code 0 will be called from ABT mode, with IRQ disabled. At the time the call is made the stack pointers for the other privileged modes will be in an indeterminate state (e.g. the abort could be due to a SVC stack overflow), so implementations must be careful to avoid using the stacks for any other modes. For example, this prevents the use of SWI calls, and it prevents the direct use of CMHG veneers in C modules. Similarly, if the abort was due to a faulty interrupt handler, re-enabling IRQs may cause the handler to crash again, so SeriousErrorV handlers must take care to not re-enable interrupts. For C modules which are only interested in the reason codes that are called in SVC mode, it's recommended to use a pre-veneer infront of the CMHG veneer which will filter out all the codes which you are not interested in. Currently reason code 0 is the only reason code which is not called in SVC mode, but more reason codes might be introduced in future, so having your pre-veneer filter out all unknown codes is the safest approach. h4. Reason codes |_<^{width:3em}. |<^. | |<^. 0|<^. Collect. Entered in ABT mode, IRQ disabled, FIQ undefined| ||R0 = [[Exception Registers Block|Pointer to register dump]]| ||R1 = Pointer to (untranslated) error block| |<^. 1|<^. Recover. Entered in SVC mode, IRQ disabled| ||R0 = Pointer to translated error block| |<^. 2|<^. Report. Entered in SVC mode, IRQ enabled| ||R0 = Pointer to translated error block| |<^. 3|<^. Custom Report. Entered in SVC mode, IRQ enabled| ||R0 = Pointer to translated error block| ||R1 = Flags| ||R3 = Pointer to callback function to receive the report| ||R4 = Callback R0| h4. Serious error processing When a serious error occurs, the kernel undertakes the following procedure: # A register dump is created, in a temporary location on the ABT or UND stack. # An appropriate untranslated error block is selected (the error number will be correct, but the message will be a meaningless message file token) # SeriousErrorV reason code 0 will be called. This allows crash reporting software such as the [[Debugger]] module to collect the key machine state at the time of the error (register dump, error code, privileged mode stack dumps, code surrounding the PC, etc). # The CPU will switch to SVC mode and the SVC stack pointer will be reset to its default value # The register dump will be copied from the stack to the location specified by the [[OS_ChangeEnvironment|environment handler]]. This occurs after the SVC stack has been reset so that the kernel can call [[OS_Memory 24]] to check that the target address is valid. If the address is invalid, it will be silently reset to the kernel default address. # The error block will be translated via [[MessageTrans]] # The stack pointers for the other privileged processor modes will be reset to their default values # Any other relevant internal state (e.g. IRQsema) will also be reset # FIQs will be re-enabled # SeriousErrorV reason code 1 will be called. This reason code is primarily to allow low-level system components to reset themselves, e.g. [[RTSupport]] needs to be notified of the SVC stack reset and the IRQsema reset. The system will still be in an indeterminate state, so code must be careful about which SWIs (if any) it calls. # IRQs will be re-enabled # SeriousErrorV reason code 2 will be called. This is primarily used to allow crash reporting software to output its report, e.g. by writing it to disc. Other machine state may also be collected at this time (e.g. anything which could not be collected during the "collect" call) # Finally, [[OS_GenerateError]] is called in order to notify the current application of the error Note that the exact ordering of items is subject to change in future kernel versions, but the overall flow as seen by SeriousErrorV will remain the same. h4. Custom report generation Software can request that a custom report is generated by calling SeriousErrorV reason codes 0 and 3. For example, when the [[ZeroPain]] module emulates a zero page access, it also invokes SeriousErrorV in order to collect information for inclusion in the log file so that the zero page access can be reported to the author of the relevant software. The process for using these reason codes is as follows: # Create a temporary register dump and error block somewhere # Enter ABT mode with IRQs disabled # Invoke SeriousErrorV reason code 0 # Enter SVC mode with IRQs enabled # Invoke SeriousErrorV reason code 3 The requirement for reason code 0 to be called in ABT mode means that there is no legal way for software outside the kernel to invoke that reason code. Therefore, at this time, the use of custom reports is restricted to low-level OS components which have enough knowledge of the host system to be able to invoke the vector directly. The flags for reason code 3 are as follows: |_<^{width:3em}. Bit |<^. Meaning | |/2<^. 0 |<^. 1 -> Produce annotated text dump | |<^. 0 -> Produce raw hex dump | |<^. 1+ |<^. Reserved | The callback function pointer provided in R3 must have the following signature: |_<^{width:3em}. Entry |<^. | |<^. R0|<^. Parameter provided to SeriousErrorV| |<^. R1 |<^. Pointer to null-terminated string| |_<^{width:3em}. Exit |<^. | |<^. R0-R3, R12 |<^. Corrupt| The callback function will be called multiple times as the different areas of the report are output.