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

[Chris Johns]

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.

Chris