OS_AbortTrap

OS SWI Calls

» OS_AbortTrap

OS_AbortTrap

(SWI &67)

Use

The abort trapping system allows for data and prefetch aborts to be handled at a higher level than previously possible (e.g. via OS_ClaimProcessorVector or the environment handlers). They are designed to be easy to use for purposes such as implementing on-demand page mapping or virtual hardware devices; i.e. where the code can interact with the address range as if it were normal memory, with the OS and AbortTrap silently handling any aborts by emulating the aborting instruction and then resuming execution.

When a data abort occurs, the kernel will decode the instruction to determine the type of access (e.g. read or write), the address range being accessed, and which registers the data should be transferred in/out of. The kernel will then attempt to emulate the load/store operation, by invoking the relevant AbortTrap handler(s) for the region.

Handlers have three ways of responding to requests:

• They can comply with the request. If enough handlers comply, then the kernel will apply the necessary register updates (e.g. performing base register writeback) and return from the abort handler, resuming execution as if the instruction had never generated the abort.
• They can fail with a serious error (bit 31 of error number set). This will cause the abort processing to be halted and the error to be raised in a similar manager to unhandled data/prefetch aborts (i.e. the exception registers block will be populated, OS_ReadSysInfo 7 will be updated, the privileged mode stacks will be flattened, and the error will be raised via OS_GenerateError).
• They can decline to handle the request, by returning with a non-serious error. In this case, the kernel will check to see if there are any other handlers for that region, without raising the error. Note that if there are multiple handlers which cover the same region, the order in which the kernel will try them is undefined.

AbortTrap handlers are invoked after the OS_ClaimProcessorVector handlers, and before the data/prefetch abort environment handlers. This means that if there’s an abort which AbortTrap isn’t able to handle (e.g. there’s a part of the address range which isn’t covered by a handler, or where the handler has declined the request), then the kernel will restore the original registers and control will pass to the data/prefetch environment handler.

AbortTrap handlers will only be invoked for translation faults (no memory at the target address) or permission faults (e.g. attempting to write to read-only memory). Other types of fault (alignment faults, or hardware faults like cache parity errors) will not result in handlers being invoked, and there is no guarantee that unpredictable instructions (e.g. LDM which loads the base register but also applies writeback) will be processed. AbortTrap processing will not be performed if there is insufficient space in the SVC stack or the kernel believes the stack pointer is corrupt.

For aborts which cross page boundaries, it’s possible that only one of the pages is responsible for generating the abort, and the other page would have been able to service the request directly without aborting. The kernel will detect this and make sure that AbortTrap handlers are only invoked for pages where the abort was necessary; for pages where no abort would be generated, the kernel will emulate the access itself by directly copying to/from the relevant address range.

When the kernel invokes an AbortTrap handler, it can ask it to do one of two things:

• Emulate a memory access by transferring data in/out of a buffer provided by the kernel. This is used for most load/store operations. For store operations, the buffer will have been filled with the values of the registers which are being stored. For load operations, the values which the AbortTrap handler writes to the buffer will be copied to the relevant registers.
• Map in memory with the indicated (minimum) permissions. This is used for prefetch aborts, and for some advanced instructions such as LDREX/STREX (which cannot safely be emulated via normal load/store instructions). For this type of request, if all the necessary handlers comply, then the kernel will return from the exception and re-execute the aborting instruction, allowing the CPU to execute it natively.

AbortTrap handlers

Care must be taken to ensure that an error is returned if the handler is called with unsupported/unrecognised reason code or flags.

For memmap operations, the permission flags are:

This is the same pattern as used by OS_Memory 18.

Notes

Where possible, it’s preferable to use Abortable Dynamic Areas instead of directly registering with OS_AbortTrap.

Code which registers AbortTrap handlers may also need to respond to Service_ValidateAddress, in order for the OS & software to consider the address range as valid.

Regions which handlers are asked to service have no size or alignment guarantees, other than the minimum size being one byte, and the requested region being fully within the low/high addresses specified when the handler was registered.

For handler reasons 0 & 1, bytes should be transferred in linear order; the kernel will take care of any rotation required by pre-ARMv7 rotated loads.

SWP/SWPB instructions are emulated as a load operation (handler reason 1) followed by a store operation (handler reason 0). If the handler maps in the page as part of the read operation, the kernel may directly emulate the store by copying the data itself.

Currently, data aborts from Thumb mode are not handled and will be passed straight on to the abort environment handler.

StrongARM abort handling errata are not dealt with, so care must be taken when using handlers on afflicted CPUs (see Notable CPU bugs).

For operations which cross multiple regions (e.g. multiple AbortTrap regions or directly-accessible memory regions), and where the overall result is a failure:

• Some AbortTrap read or write operations may have been performed
• For write instructions, some directly-accessible memory may have been updated

This behaviour is broadly consistent with the ARM abort model.

This call is available in RISC OS Select and RISC OS 5.29+. Differences between RISC OS 5 and RISC OS Select are:

• RISC OS 5 supports all ARMv3-ARMv8 load/store instructions, including FPA, VFP and NEON
• RISC OS 5 adds support for memmap operations
• RISC OS 5 adds support for processing prefetch aborts via AbortTrap

See also

• OS_ClaimProcessorVector
• Environment Handlers
• Service_ValidateAddress
• Abortable Dynamic Areas