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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
