|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
SEH in RISC Environments
In a RISC environment, data structures associated with exception processing are calculated at compile time, and written to the data sections of the module being built.
To locate appropriate handlers when an exception occurs in Win32 environments other than x86, the system first determines the frames that reside on the callstack, along with their associated functions in code. Any function can have a handler associated with it. If so, the system gives the handler associated with the function an opportunity to handle the exception.
As with x86, a RISC system invokes handlers in reverse order; that is, it first invokes the handler whose corresponding frames were most recently pushed onto the stack.
To determine the frames on the stack, the system simulates the execution of a portion of each function's code in reverse. This simulation creates a CPU context similar to the state the real CPU context held at the point of entry to that function.
This process of reverse execution is known as Virtual Unwinding, because the stack unwind is only being simulated, not actually performed.
Code elements for unwinding
The portion of the code that is reversed is known as the Prolog of the function. It consists of instructions that modify the stack pointer and set up the stack frame immediately upon entry to the function.
When a frame has been virtually unwound, the virtual context contains the stack pointer for the previous frame and the return address for the current function. The return address is very near the place where control left the previous function, so it corresponds to the program counter of the previous frame.
With each successive program counter and stack pointer, the unwind process can iterate until there are no frames left on the stack.
To virtually unwind, the system needs a small amount of information about each function. This information is contained in data structures called PDATA Structures.
A PDATA structure marks where a function begins and ends in the code stream, as well as the location of the function prolog.
Given a program counter associated with a specific stack frame, the Unwinder searches the table of PDATA for the entry corresponding to the containing function. When found, the Unwinder can unwind the function frame.
The PDATA structure also locates an exception handling routine associated with the function, if one exists.
The compiler generates correct Prolog and Epilog sequences, and PDATA for functions that it compiles, but you must create appropriate code and PDATA for functions you write in assembly language.
The prolog and epilog sequence must adhere to strict guidelines for Virtual Unwinding to work.
For details on acceptable prologs and epilogs, see the documentation for your target platform.