[PATCH v2 5/6] cpukit: Add signal mapping support

[Kinsey Moore]

On 9/22/2021 21:06, Chris Johns wrote:
> On 23/9/21 10:16 am, Kinsey Moore wrote:
>> This adds a confdef option allowing an application to request mapping
>> machine exceptions to POSIX signals. This is required for some languages
>> such as Ada.> --- a/cpukit/include/rtems/confdefs/extensions.h
>> +++ b/cpukit/include/rtems/confdefs/extensions.h
>> @@ -93,6 +93,10 @@
>>     #include <rtems/stackchk.h>
>>   #endif
>>   
>> +#ifdef CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING
>> +  #include <rtems/exception.h>
>> +#endif
>> +
>>   #ifdef __cplusplus
>>   extern "C" {
>>   #endif
>> @@ -103,6 +107,9 @@ extern "C" {
>>     || defined(CONFIGURE_INITIAL_EXTENSIONS) \
>>     || defined(BSP_INITIAL_EXTENSION)
>>     const User_extensions_Table _User_extensions_Initial_extensions[] = {
>> +    #ifdef CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING
>> +      { .fatal = _Exception_map_signal },
> There is something amiss adding a recoverable interface and support that hooks
> `.fatal`. Either this field is now badly named or should there be something else
> added? Another extension? I do not know.
I agree and that's partially the reason my previous patch had this split 
out into a different extension type. This API is not something I feel 
comfortable breaking for users, so I'd lean away from renaming it. My 
takeaway from our discussion was that this should be implemented as a 
fatal error extension with an epilogue function to break out of the 
normal call stack and perform exception cleanup tasks.
> What happens to my default fatal handler if I decide to enable this support?

If you enable this support, some fatal errors will be deemed recoverable 
and recovered errors will not propagate to further fatal error handlers. 
If enabled, handlers of this variety must run first to avoid any side 
effects on the system caused by other fatal handlers taking final 
actions on what they expect is a dead system.


Kinsey