Adding an application SVC handler when using debug hardware

Many applications require their own SVC handlers in addition to semihosting SVCs. To ensure that the application SVC handler cooperates with the debug hardware semihosting mechanism, use your debugger to:

  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 the following example.

Example 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 debug hardware semihosting as shown in the following example.

Example 2. SVC handler with debug hardware 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.
	Semi_SVC
    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 debug 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 debug software does not know about, because the SEMIHOST_VECTOR address has moved to a place that cannot currently be reached.

Note

If semihosting is not used 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 debug hardware 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 debug 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 debug hardware-based system, you must convert to the debug hardware way of installing the application and semihosted SVC handlers.

Show/hideSee also

Copyright © 2010-2011 ARM. All rights reserved.ARM DUI 0498D
Non-ConfidentialID071311