[PATCH v1 1/3] cpukit: Add signal mapping support

[Kinsey Moore]

On 4/20/2021 01:44, Chris Johns wrote:
> On 20/4/21 4:38 pm, Sebastian Huber wrote:
>> On 20/04/2021 08:30, Chris Johns wrote:
>>> On 20/4/21 3:54 pm, Sebastian Huber wrote:
>>>> On 20/04/2021 07:30, Chris Johns wrote:
>>>>
>>>>> We need a way for libdebugger or any other piece of software to capture and
>>>>> cascade the call. If this can be done on aarch64 then I am happy.
>>>> The fatal error extensions execute in a user controllable order. You can for
>>>> example register a libdebugger handler which deals with break point exceptions
>>>> before the signal mapping handler is called.
>>>>
>>>> Synchronous exceptions should end up in an RTEMS_FATAL_SOURCE_EXCEPTION fatal
>>>> error. The fatal code is a pointer to rtems_exception_frame
>>>> (CPU_Exception_frame). In this data structure should be the complete state of
>>>> the interrupted context (which could be also an interrupt handler). If you want
>>>> to resume execution of the interrupted context, then we need an API for this
>>>> (setters/getters and some sort of a longjmp()).
>>> I do not think the fatal error handler support is suitable for a debugger, the
>>> frame maybe on the wrong stack. It was more complicated to implement than this
>>> and the reality of what is needed on the ARM required lots more. The fatal error
>>> handler handles fatal errors however surviving a data abort and then continuing
>>> in the correct CPU context/space and stack is much harder to do ....
>>>
>>> https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n1454
>>>
>>> That code has to work with all data and states saved.
>> Yes, this code is the "some sort of a longjump()". The code mentioned above
>> doesn't seem to be necessarily libdebugger-specific.
> Ah OK we agree :). I would love to see that happen.
>
> The fatal error handler API would then be built on an exception management API.
> I personally believe this is a key piece of functionality RTEMS would benefit
> from. It would make adding signal support easy.


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 thread 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 if necessary


     handler gets CEF as only argument
     handler return value determines whether it took final actions based 
on the CEF

     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)


Kinsey