User guide

ManualsBrandsARM ManualsComputer HardwareVERSION 1.2

5.10 Chaining exception handlers

In some situations there can be several different sources of a particular exception. For example:

• Angel uses an Undefined Instruction to implement breakpoints. However, Undefined Instruction exceptions also

occur when a coprocessor instruction is executed, and no coprocessor is present.

• Angel uses a SWI for various purposes, such as entering Supervisor mode from User mode, and supporting

semihosting requests during development. However, an RTOS or an application might also implement some

SWIs.

In such situations there are two approaches that can be taken to extend the exception handling code:

• A single extended handler

• Several chained handlers.

5.10.1 A single extended handler

In some circumstances it is possible to extend the code in the exception handler to work out what the source of the

exception was, and then directly call the appropriate code. In this case, you are modifying the source code for the

exception handler.

Angel has been written to make this approach simple. Angel decodes SWIs and Undefined Instructions, and the

Angel exception handlers can be extended to deal with non-Angel SWIs and Undefined Instructions.

However, this approach is only useful if all the sources of an exception are known when the single exception handler

is written.

5.10.2 Several chained handlers

Some circumstances require more than a single handler. Consider the situation in which a standard Angel debugger

is executing, and a standalone user application (or RTOS) which wants to support some additional SWIs is then

downloaded. The newly loaded application may well have its own entirely independent exception handler that it wants

to install, but which cannot simply replace the Angel handler.

In this case the address of the old handler must be noted so that the new handler is able to call the old handler if it

discovers that the source of the exception is not a source it can deal with. For example, an RTOS SWI handler would

call the Angel SWI handler on discovering that the SWI was not an RTOS SWI, so that the Angel SWI handler gets a

chance to process it.

This approach can be extended to any number of levels to build a chain of handlers. Although code that takes this

approach allows each handler to be entirely independent, it is less efficient than code that uses a single handler, or at

least it becomes less efficient the further down the chain of handlers it has to go.

Both routines given in Installing the handlers from C return the old contents of the vector. This value can be decoded

to give:

The offset for a branch instruction

This can be used to calculate the location of the original handler and allow a new branch

instruction to be constructed and stored at a suitable place in memory. If the replacement handler

fails to handle the exception, it can branch to the constructed branch instruction, which in turn will

branch to the original handler.

The location used to store the address of the original handler

If the application handler failed to handle the exception, it would then need to load the program

counter from that location.

In most cases, such calculations are not necessary because information on the debug monitor or RTOS handlers is

available to you. If so, the instructions required to chain in the next handler can be hard-coded into the application.

The last section of the handler must check that the cause of the exception has been handled. If it has, the handler

can return to the application. If not, it must call the next handler in the chain.

Note

When chaining in a handler before a debug monitor handler, you must remove the chain when the monitor is

removed from the system, then directly install the application handler.

Handling Processor Exceptions