[PATCH v1 1/3] cpukit: Add signal mapping support
gedare at rtems.org
Mon Apr 26 19:08:20 UTC 2021
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
> 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 :)
More information about the devel