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

[Sebastian Huber]

On 23/09/2021 04:41, Kinsey Moore wrote:
> 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.

The "fatal" extension should definitely not get renamed. This extension 
was generalized over time. Thanks to the fatal source parameter this 
extension is easy to extend.

> 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.

Yes, exactly.

>> 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.

Yes, exactly. The fatal extensions have a well defined order (position 
in the table). The user has the full control over the initial extensions 
table.

-- 
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at 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/