On 4/16/2021 08:48, Gedare Bloom wrote:
On Fri, Apr 16, 2021 at 1:19 AM Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
Hello Kinsey,
why don't you use a fatal error extension for this? You can save all the
processor state to a structure and use it to jump to previous or next
instruction it if needed in a custom fatal error handler which deals
with RTEMS_FATAL_EXCEPTION. I think libdebugger uses this approach.
+1
This is otherwise a major overhaul/addition to the CPU port
requirements. I'd lean in favor of adding any CPU_* API that is
necessary to support vectoring from an exception to a signal. I don't
think we can make this kind of intrusive modification to basic
interrupt handling capabilities across all ports easily. Some of that
code is old and very stable.
I avoided going that direction to maintain the interrupt stack since an
exception return from within those handlers would necessarily leave the
CPU state as well as intervening functions on the stack along with a
minor amount of data on the thread stack. In addition, thread dispatch
needs to occur and all exception handling for AArch64 (as modeled after
ARM) is currently considered final with no way to reasonably return to
execution.
Not every platform will need this kind of intrusive change. Any platform
that handles exceptions in a manner similar to IRQs can deal with this
exception mapping far more trivially. ARM and AArch64 don't have that
luxury, but SPARC does and I assume others do as well.
Kinsey
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
