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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
