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

[Gedare Bloom]

On Fri, Apr 23, 2021 at 8:28 AM Kinsey Moore <kinsey.moore at oarcorp.com> wrote:
>
> 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)
>

I think this belongs in a new thread for discussion and easier
search/reference in future. This smells important :)

>
> Kinsey
>