Re: [PATCH v2 5/6] cpukit: Add signal mapping support
On 05/10/2021 03:51, Chris Johns wrote: On 5/10/21 4:29 am, Sebastian Huber wrote: On 02/10/2021 01:44, Chris Johns wrote: The fatal extensions have a well defined order (position in the table). The user has the full control over the initial extensions table. Is it backwards compatible when this new mode is enabled? When you enable a new feature you get new behaviour. I am not sure what you mean with backward compatible in this case. If you don't enable the exception to signal mapping (default), then nothing changes. "The user has the full control over the initial extensions table." Does this option change that? Is this feature mutually exclusive or additive to any "current control" a user has? In other words, it is not clear to me if I can add this option and still maintain any existing controls I may have. If it is not and users need to make changes the user code becomes a mess of version defines. Is that what we want? If you add the new option similar to the stack checker option #ifdef CONFIGURE_STACK_CHECKER_ENABLED RTEMS_STACK_CHECKER_EXTENSION, #endif then you can either use the application configuration option to enable the extension at the recommended position or you can use the extension define in your CONFIGURE_INITIAL_EXTENSIONS exactly where you want it. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 5/6] cpukit: Add signal mapping support
On 5/10/21 4:29 am, Sebastian Huber wrote: > On 02/10/2021 01:44, Chris Johns wrote: >>> The fatal extensions have a well defined order (position in the >>> table). The user has the full control over the initial extensions table. >> Is it backwards compatible when this new mode is enabled? > > When you enable a new feature you get new behaviour. I am not sure what you > mean > with backward compatible in this case. If you don't enable the exception to > signal mapping (default), then nothing changes. "The user has the full control over the initial extensions table." Does this option change that? Is this feature mutually exclusive or additive to any "current control" a user has? In other words, it is not clear to me if I can add this option and still maintain any existing controls I may have. If it is not and users need to make changes the user code becomes a mess of version defines. Is that what we want? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 5/6] cpukit: Add signal mapping support
On 02/10/2021 01:44, Chris Johns wrote: The fatal extensions have a well defined order (position in the table). The user has the full control over the initial extensions table. Is it backwards compatible when this new mode is enabled? When you enable a new feature you get new behaviour. I am not sure what you mean with backward compatible in this case. If you don't enable the exception to signal mapping (default), then nothing changes. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 5/6] cpukit: Add signal mapping support
On 1/10/21 11:33 pm, Sebastian Huber wrote: > The fatal extensions have a well defined order (position in the > table). The user has the full control over the initial extensions table. Is it backwards compatible when this new mode is enabled? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 5/6] cpukit: Add signal mapping support
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
#endif
+#ifdef CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING
+ #include
+#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.hu...@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/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 5/6] cpukit: Add signal mapping support
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
#endif
+#ifdef CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING
+ #include
+#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
Re: [PATCH v2 5/6] cpukit: Add signal mapping support
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
> #endif
>
> +#ifdef CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING
> + #include
> +#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.
What happens to my default fatal handler if I decide to enable this support?
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v2 5/6] cpukit: Add signal mapping support
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.
---
cpukit/doxygen/appl-config.h | 25 -
cpukit/include/rtems/confdefs/extensions.h | 7 ++
cpukit/include/rtems/exception.h | 12 +++
cpukit/score/src/exceptionmapping.c| 106 +
spec/build/cpukit/librtemscpu.yml | 2 +
spec/build/cpukit/objexceptionmapping.yml | 15 +++
6 files changed, 166 insertions(+), 1 deletion(-)
create mode 100644 cpukit/score/src/exceptionmapping.c
create mode 100644 spec/build/cpukit/objexceptionmapping.yml
diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index bbeb438bec..8ad3a3c70e 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -3,7 +3,7 @@
/*
* Copyright (C) 2019, 2021 embedded brains GmbH
(http://www.embedded-brains.de)
* Copyright (C) 2010 Gedare Bloom
- * Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
+ * Copyright (C) 1988, 2021 On-Line Applications Research Corporation (OAR)
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -1773,6 +1773,29 @@
*/
#define CONFIGURE_ATA_DRIVER_TASK_PRIORITY
+/* Generated from spec:/acfg/if/exception-to-signal-mapping */
+
+/**
+ * @brief This configuration option is a boolean feature define.
+ *
+ * In case this configuration option is defined, then the machine exception to
+ * POSIX signal mapping is configured during system initialization.
+ *
+ * @par Default Configuration
+ * If this configuration option is undefined, then the described feature is not
+ * enabled.
+ *
+ * @par Notes
+ * @parblock
+ * This device driver is responsible for setting up a mapping from machine
+ * exceptions to POSIX signals so that applications may consume them and alter
+ * task execution as necessary.
+ *
+ * This is especially useful for applications written in Ada or C++.
+ * @endparblock
+ */
+#define CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING
+
/* Generated from spec:/acfg/if/max-drivers */
/**
diff --git a/cpukit/include/rtems/confdefs/extensions.h
b/cpukit/include/rtems/confdefs/extensions.h
index 83d690d50a..767c9028d1 100644
--- a/cpukit/include/rtems/confdefs/extensions.h
+++ b/cpukit/include/rtems/confdefs/extensions.h
@@ -93,6 +93,10 @@
#include
#endif
+#ifdef CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING
+ #include
+#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 },
+#endif
#ifdef _CONFIGURE_RECORD_NEED_EXTENSION
{
#ifdef CONFIGURE_RECORD_EXTENSIONS_ENABLED
diff --git a/cpukit/include/rtems/exception.h b/cpukit/include/rtems/exception.h
index 89edfd02b4..547d7c42c2 100644
--- a/cpukit/include/rtems/exception.h
+++ b/cpukit/include/rtems/exception.h
@@ -159,6 +159,18 @@ void Exception_Manager_Copy_CPU_Exception_frame(
CPU_Exception_frame *old_ef
);
+/**
+ * @brief Handle an exception frame for mapping signals
+ *
+ * See CONFIGURE_EXCEPTION_TO_SIGNAL_MAPPING documentation in the
+ * "RTEMS Classic API Guide".
+ */
+void _Exception_map_signal(
+ Internal_errors_Source source,
+ bool always_set_to_false,
+ Internal_errors_t code
+);
+
#ifdef __cplusplus
}
#endif
diff --git a/cpukit/score/src/exceptionmapping.c
b/cpukit/score/src/exceptionmapping.c
new file mode 100644
index 00..a1b1146d1c
--- /dev/null
+++ b/cpukit/score/src/exceptionmapping.c
@@ -0,0 +1,106 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreExceptionMapping
+ *
+ * @brief AArch64 machine exception to POSIX signal mapping.
+ */
+
+/*
+ * Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY
