Currently, code that needs to consume exceptions has two points where it can hook exceptions:
1) The consumer can hook the exception vectors directly. This allows for full control of how the exceptions are handled, but requires very low level platform-specific code even where it might not otherwise be strictly necessary. 2) The consumer can utilize the existing fatal extensions framework. This obviates the need for platform-specific code and provides a CPU Exception Frame if it is necessary for additional details. Fatal extensions assume that any exception is terminal and that the CPU will not return to normal program flow. Accomplishing a return to normal program flow from this interface is only possible by writing quite a bit of fragile platform-specific low level code that would have to be carefully maintained with changes to each platform it supports while not being directly linked to it in any way. Recently, I had a need to port the exception to signal mapping code from the SPARC platform to AArch64 to support Ada (other runtimes may also need such mappings). This code could be written in a platform-agnostic way, but there is not currently an interface available that suits that need, so I was forced to use option 1) above. Obviously, this makes Ada support non-trivial on any platform where it doesn't already exist even though the vast majority of the mapping code does not need to deal with the platform underpinnings. With the above constraints, it was suggested that perhaps RTEMS needs an Exception Management API upon which both the exception to signal mapping and fatal extensions can be built. This would also trivially allow other platform-agnostic exception handlers to be written for other system management use cases. Libdebugger also uses option 1) above and much of the platform-specific code could be left to an exception management layer. My initial thoughts on an Exception Management API (EMAPI): Additional CPU port requirements for EMAPI support: Provide functions which operate on CPU Exception Frame (CEF) Get address of exception Get exception class (these will be as granular as possible while still being arch-agnostic) Set address to resume execution as instruction after exception Set address to resume execution (arbitrary) Upon exception, creates CEF on exception stack and calls into EMAPI Upon return from EMAPI, restores CEF and returns to normal execution EMAPI: No architecture-specific information is directly exposed CEF is provided as a handle on which to operate Architecture-specific details can be pulled from CEF Handler gets CEF as only argument Handler return value determines whether it took final actions Handler list is ordered based on priority, but not otherwise keyed A handler that takes a final action prevents execution of further handlers Lowest priority handler is always present Frame dump and fatal extensions run here For libdebugger, it would also be helpful if the CPU port could be relied on to switch operating modes and move the CEF to the appropriate stack, accordingly. I'm sure there are some details I've missed here, but I think this is enough to get the work started. Kinsey
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel