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