SeriousErrorV (changes)

Showing changes from revision #3 to #4: Added | Removed | Changed

Programmer's Reference Manuals

» Vectors

» Software Vector Numbers

» SeriousErrorV

SeriousError Vector (44) (45)

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.

Reason codes

Serious error processing

When a serious error occurs, the kernel undertakes the following procedure:

1. A register dump is created, in a temporary location on the ABT or UND stack.
2. An appropriate untranslated error block is selected (the error number will be correct, but the message will be a meaningless message file token)
3. 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).
4. The CPU will switch to SVC mode and the SVC stack pointer will be reset to its default value
5. The register dump will be copied from the stack to the location specified by the 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.
6. The error block will be translated via MessageTrans
7. The stack pointers for the other privileged processor modes will be reset to their default values
8. Any other relevant internal state (e.g. IRQsema) will also be reset
9. FIQs will be re-enabled
10. 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.
11. IRQs will be re-enabled
12. 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)
13. 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.

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:

1. Create a temporary register dump and error block somewhere
2. Enter ABT mode with IRQs disabled
3. Invoke SeriousErrorV reason code 0
4. Enter SVC mode with IRQs enabled
5. 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:

The callback function pointer provided in R3 must have the following signature:

The callback function will be called multiple times as the different areas of the report are output.