[PATCH v1 3/5] cpukit/aarch64: Add Exception Manager support

[Kinsey Moore]

On 9/1/2021 10:58, Sebastian Huber wrote:
> On 01/09/2021 17:48, Sebastian Huber wrote:
>> So, my proposal would be something like this:
>>
>> 1. Processor jumps to exception prologue
>>
>> 2. Exception prologue saves the context to CPU exception frame
>>
>> 3. Exception prologue calls rtems_fatal() which does not return
>>
>> For the signal mapping you provide a fatal extension:
>>
>> 1. If the source is not RTEMS_FATAL_SOURCE_EXCEPTION, then return 
>> (system terminates).
>>
>> 2. If the exception type cannot be handled, then return (system 
>> terminates).
>>
>> 3. Add a post-switch action to the executing thread.
>>
>> 4. Call _CPU_Exception_return( frame )
>>
>> The  _CPU_Exception_return( frame ) should:
>>
>> 1. Save the CPU exception return information to the stack of the 
>> executing thread.
>>
>> 2. Switch to the stack of the executing thread and to thread context 
>> with interrupts disabled.
>>
>> 3. Do something similar to the interrupt return.
>>
>> 4. The thread dispatch will call the post-switch extension which 
>> could raise a signal.
>>
>> This approach avoids a new user extension and it avoids a potentially 
>> dead code in the exception epilogue.
>
> Chris, I guess you have something like this
>
> _CPU_Exception_return( frame )
>
> in libdebugger currently?
>
I expected that since libdebugger wasn't built on the fatal error 
extension mechanism that it wasn't suitable for that type of functionality.

One thing I've been trying to avoid with the current approach is manual 
unwinding of the exception stack and the side-effects of other fatal 
error extensions. I suppose I could orchestrate the ordering of existing 
extensions such that recoverable exception handlers run before anything 
else.


Kinsey