[PATCH v1 1/3] cpukit: Add signal mapping support

[Kinsey Moore]

On 4/16/2021 08:48, Gedare Bloom wrote:
> On Fri, Apr 16, 2021 at 1:19 AM Sebastian Huber
> <sebastian.huber at 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