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?
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
