<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Currently, code that needs to consume exceptions has two points where it can<o:p></o:p></p>
<p class="MsoNormal">hook exceptions:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1) The consumer can hook the exception vectors directly.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> This allows for full control of how the exceptions are handled, but requires<o:p></o:p></p>
<p class="MsoNormal"> very low level platform-specific code even where it might not otherwise be<o:p></o:p></p>
<p class="MsoNormal"> strictly necessary.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2) The consumer can utilize the existing fatal extensions framework.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> This obviates the need for platform-specific code and provides a<o:p></o:p></p>
<p class="MsoNormal"> CPU Exception Frame if it is necessary for additional details. Fatal<o:p></o:p></p>
<p class="MsoNormal"> extensions assume that any exception is terminal and that the CPU will not<o:p></o:p></p>
<p class="MsoNormal"> return to normal program flow. Accomplishing a return to normal program flow<o:p></o:p></p>
<p class="MsoNormal"> from this interface is only possible by writing quite a bit of fragile<o:p></o:p></p>
<p class="MsoNormal"> platform-specific low level code that would have to be carefully maintained<o:p></o:p></p>
<p class="MsoNormal"> with changes to each platform it supports while not being directly linked to<o:p></o:p></p>
<p class="MsoNormal"> it in any way.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Recently, I had a need to port the exception to signal mapping code from the<o:p></o:p></p>
<p class="MsoNormal">SPARC platform to AArch64 to support Ada (other runtimes may also need such<o:p></o:p></p>
<p class="MsoNormal">mappings). This code could be written in a platform-agnostic way, but there is<o:p></o:p></p>
<p class="MsoNormal">not currently an interface available that suits that need, so I was forced to<o:p></o:p></p>
<p class="MsoNormal">use option 1) above. Obviously, this makes Ada support non-trivial on any<o:p></o:p></p>
<p class="MsoNormal">platform where it doesn't already exist even though the vast majority of the<o:p></o:p></p>
<p class="MsoNormal">mapping code does not need to deal with the platform underpinnings.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">With the above constraints, it was suggested that perhaps RTEMS needs an<o:p></o:p></p>
<p class="MsoNormal">Exception Management API upon which both the exception to signal mapping and<o:p></o:p></p>
<p class="MsoNormal">fatal extensions can be built. This would also trivially allow other<o:p></o:p></p>
<p class="MsoNormal">platform-agnostic exception handlers to be written for other system management<o:p></o:p></p>
<p class="MsoNormal">use cases. Libdebugger also uses option 1) above and much of the platform-specific<o:p></o:p></p>
<p class="MsoNormal">code could be left to an exception management layer.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">My initial thoughts on an Exception Management API (EMAPI):<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Additional CPU port requirements for EMAPI support:<o:p></o:p></p>
<p class="MsoNormal"> Provide functions which operate on CPU Exception Frame (CEF)<o:p></o:p></p>
<p class="MsoNormal"> Get address of exception<o:p></o:p></p>
<p class="MsoNormal"> Get exception class (these will be as granular as possible<o:p></o:p></p>
<p class="MsoNormal"> while still being arch-agnostic)<o:p></o:p></p>
<p class="MsoNormal"> Set address to resume execution as instruction after exception<o:p></o:p></p>
<p class="MsoNormal"> Set address to resume execution (arbitrary)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> Upon exception, creates CEF on exception stack and calls into EMAPI<o:p></o:p></p>
<p class="MsoNormal"> Upon return from EMAPI, restores CEF and returns to normal execution<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">EMAPI:<o:p></o:p></p>
<p class="MsoNormal"> No architecture-specific information is directly exposed<o:p></o:p></p>
<p class="MsoNormal"> CEF is provided as a handle on which to operate<o:p></o:p></p>
<p class="MsoNormal"> Architecture-specific details can be pulled from CEF<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> Handler gets CEF as only argument<o:p></o:p></p>
<p class="MsoNormal"> Handler return value determines whether it took final actions<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> Handler list is ordered based on priority, but not otherwise keyed<o:p></o:p></p>
<p class="MsoNormal"> A handler that takes a final action prevents execution of further handlers<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"> Lowest priority handler is always present<o:p></o:p></p>
<p class="MsoNormal"> Frame dump and fatal extensions run here<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">For libdebugger, it would also be helpful if the CPU port could be relied on<o:p></o:p></p>
<p class="MsoNormal">to switch operating modes and move the CEF to the appropriate stack,<o:p></o:p></p>
<p class="MsoNormal">accordingly. I’m sure there are some details I’ve missed here, but I think<o:p></o:p></p>
<p class="MsoNormal">this is enough to get the work started.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kinsey<o:p></o:p></p>
</div>
</body>
</html>