Conventionally, this issue has been addressed by using one of two approaches to prevent the occurrence of a second exception. Under the first approach, the exception handler takes additional steps to ensure that a second exception cannot occur when the exception handler attempts to store state data for the first exception. For example, the processor-based device may allocate dedicated memory pages for the exception stack that are guaranteed to always be accessible, and the exception handler may include an instruction sequence(s) to guarantee that a stack pointer used to access the exception stack can never reference an address outside the dedicated memory pages. The second approach requires that the exception handler take additional steps to precheck the stack pointer's value before attempting to store state data. If the exception handler determines that use of the stack pointer will result in a second exception, the exception handler may either store the state data in an alternate location, or may correct the stack pointer value so that use of the stack pointer will no longer lead to a second exception. Both of these approaches, though, may require additional processing and/or additional system resources that may result in reduced processor performance and reduced system flexibility.

Accordingly, it is desirable to provide a mechanism for exception stack management to ensure that exception state data for a first exception can be successfully preserved even if a second exception occurs within the exception handler, while avoiding the performance penalties incurred by existing mechanisms.