On Fri, Apr 23, 2021 at 8:28 AM Kinsey Moore <kinsey.mo...@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 > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
