Exception Management

[Kinsey Moore]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210427/0680c897/attachment-0001.html>