5.2.2. Adding an application SVC handler when using RealView ICE

Many applications require their own SVC handlers in addition to semihosting SVCs. To ensure that the application SVC handler cooperates with the RealView ICE semihosting mechanism:

  1. Install the application SVC handler into the vector table.

  2. Modify the value of SEMIHOST_VECTOR to point to a location that is only reached if your handler does not recognize the SVC, or recognizes it as a semihosting SVC.

For example, a particular SVC handler might detect if it has failed to handle a SVC and branch to an error handler. An example of a basic exception handler is shown in Example 5.1.

Example 5.1. Basic SVC handler

                             ; r0 = 1 if SVC handled
    CMP r0, #1               ; Test if SVC has been handled.
    BNE NoSuchSVC            ; Call unknown SVC handler.
    LDMFD sp!, {r0}          ; Unstack SPSR...
    MSR spsr_cf, r0          ; ...and restore it.
    LDMFD sp!, {r0-r12, pc}^ ; Restore registers and return.

You can modify this code for use in conjunction with RealView ICE semihosting as shown in Example 5.2.

Example 5.2. SVC handler with RealView ICE link

                            ; r0 = 1 if SVC handled
    CMP r0, #1              ; Test if SVC has been handled.
    LDMFD sp!, {r0}         ; Unstack SPSR...
    MSR spsr_cf, r0         ; ...and restore it.
    LDMFD sp!, {r0-r12, lr} ; Restore registers.
    MOVEQS pc, lr           ; Return if SVC handled.
    MOVS pc, lr

You must then set up the SEMIHOST_VECTOR with the address of Semi_SVC. The instruction at this address is never actually executed because the RealView ICE software returns directly to the application after processing the semihosted SVC. Using a normal SVC return instruction ensures that the application does not crash if the semihosting breakpoint is not set up.

If the application is linked with the semihosted ARM C library, and therefore uses the C library startup code, you must change the contents of SEMIHOST_VECTOR before the application installs its own handler, typically by setting a breakpoint in the main code. This is because, if SEMIHOST_VECTOR is set to the fall-through part of the application SVC handler before the application starts execution, the semihosted SVCs that are called by the library initialization can trigger an unknown breakpoint error. At this point, the SVC vector has not yet had the application handler written to it, and might still contain the software breakpoint bit pattern. This triggers a breakpoint that the RealView ICE software does not know about, because the SEMIHOST_VECTOR address has moved to a place that cannot currently be reached.


If semihosting is not required by your application, including the startup code, you can simplify this process by setting SEMIHOST_ENABLED to zero.

You must take care when moving an application that previously ran in conjunction with the Angel debug monitor onto a RealView ICE system. On Angel debug monitor systems, application SVC handlers are typically added by moving and adjusting the contents of the Angel-installed SVC vector to another place, and installing the application SVC handler into the SVC vector. This method does not apply to the RealView ICE software because there is no instruction to move out of the SVC vector, and no code to jump to. Therefore, when moving an application onto a RealView ICE-based system, you must convert to the RealView ICE way of installing the application and semihosted SVC handlers.

Copyright © 2002, 2004-2008 ARM Limited. All rights reserved.ARM DUI 0155J