On 2/9/21 3:36 am, Kinsey Moore wrote: > On 9/1/2021 10:58, Sebastian Huber wrote: >> On 01/09/2021 17:48, Sebastian Huber wrote: >>> So, my proposal would be something like this: >>> >>> 1. Processor jumps to exception prologue >>> >>> 2. Exception prologue saves the context to CPU exception frame >>> >>> 3. Exception prologue calls rtems_fatal() which does not return >>> >>> For the signal mapping you provide a fatal extension: >>> >>> 1. If the source is not RTEMS_FATAL_SOURCE_EXCEPTION, then return (system >>> terminates). >>> >>> 2. If the exception type cannot be handled, then return (system terminates). >>> >>> 3. Add a post-switch action to the executing thread. >>> >>> 4. Call _CPU_Exception_return( frame ) >>> >>> TheĀ _CPU_Exception_return( frame ) should: >>> >>> 1. Save the CPU exception return information to the stack of the executing >>> thread. >>> >>> 2. Switch to the stack of the executing thread and to thread context with >>> interrupts disabled. >>> >>> 3. Do something similar to the interrupt return. >>> >>> 4. The thread dispatch will call the post-switch extension which could raise >>> a signal. >>> >>> This approach avoids a new user extension and it avoids a potentially dead >>> code in the exception epilogue. >> >> Chris, I guess you have something like this >> >> _CPU_Exception_return( frame ) >> >> in libdebugger currently? >> > I expected that since libdebugger wasn't built on the fatal error extension > mechanism that it wasn't suitable for that type of functionality. > > One thing I've been trying to avoid with the current approach is manual > unwinding of the exception stack and the side-effects of other fatal error > extensions. I suppose I could orchestrate the ordering of existing extensions > such that recoverable exception handlers run before anything else. >
[ sorry, just catching up ] The most difficult back end for libdebugger is ARM. The vectors are caught here: https://git.rtems.org/rtems/tree/cpukit/libdebugger/rtems-debugger-arm.c#n1712 at the cp15 level so they are naked. In the current code the stack frame needs to be left untouched. The exception is handled in C with: static void __attribute__((naked)) target_exception_supervisor_call(void) { CPU_Exception_frame* frame; ARM_SWITCH_REG; /* * The PC offset needs to be reviewed so we move past a svc * instruction. This can then be used as a user breakpoint. The issue is * this exception is used by the BKPT instruction in the prefetch abort * handler to signal a TRAP. */ EXCEPTION_ENTRY_EXC(); arm_debug_break_unload(); arm_debug_enable_interrupts(); EXCEPTION_ENTRY_THREAD(frame); frame->vector = 2; target_exception(frame); EXCEPTION_EXIT_THREAD(frame); arm_debug_commit_interrupt_disable(); arm_debug_break_load(); EXCEPTION_EXIT_EXC(); } The macros EXCEPTION_ENTRY_THREAD and EXCEPTION_EXIT_THREAD is the difficult asm code where the exception stack frame is copied from the exception stack to the executing thread's stack and back again. This is important because the model is now per thread so once the executing thread is suspended other threads can run and other exceptions can occur. The call `target_exception(frame);` is on the thread's stack and CPU context so all normal thread calls can happen including blocking. I suppose you could move the EXCEPTION_ENTRY_EXC processing down a level or so but the asm code handling this would need to adjust to the different stack layout and I am not sure how this gets effected by -O levels. The hard part of moving to _CPU_Exception_return( frame ) is how you recreate the return path exception stack's frame for those bits that are outside your view. I suppose you could copy to the thread's stack the exception stack frame from the top of the passed frame to a dummy word on the called functions local stack? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel