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

[Chris Johns]

On 17/4/21 10:00 am, Kinsey Moore wrote:
> 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.

How would a user in an application debug a data abort error if all they get is a
signal?

How would this type of signal support be implemented on the 32bit ARM arch and
maintain libdebugger support?

How would libdebugger be integrated on the aarch64 with this change?

Chris