Showing changes from revision #6 to #7:
Added | Removed | Changed
Entry | |
---|---|
R0 | Workspace pointer |
Other registers: Undefined | |
User mode, IRQs+FIQs enabled |
The error buffer contains (R3 the from following:OS_ChangeEnvironment) will contain the following:
+0 | PC at which the error occurred |
+4 | Error number |
+8 | Error message text |
Called This handler is called by the default claimant of ErrorV when an error occurs. It should restore all handlers to their original values and then call OS_GenerateError to pass the error to the previous handler.ErrorV? when an error occurs. It should restore all handlers to their original values and then call the non-X form of OS_GenerateError to pass the error to the previous handler.
This handler is entered in USER mode with the workspace pointer in R0, as opposed to the conventional R12.
The block should allow be for at up least to 260 bytes, bytes in size: 4 bytes for the erroring program counter plus 256 for astandard RISC OS error block. Note that the printed PRM is vague in specifying a “256 byte error buffer”, currently the kernel truncates any error message text to 252 bytes, totalling 4 + 4 + 252 = 260 in the worst case.
There is no guarantee that R13 may will be contain undefined, a either valid avoid stack pointer. Even if the use foreground of task was using R13 as a stack in the handler usual or manner, provide there your is own no stack guarantee space. that the pointer is still valid – e.g. anRTSupport routine running in SYS mode, or a non-transient callback, may have been using R13 for some other purpose at the time the error was generated. Therefore if a stack is required, it’s recommended that you validate R13, or use a different stack private to the error handler.
It’s also possible that R1-R12 and R14 do not correspond to the values they had when the error was generated.