|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [xen master] misra: consider conversion from UL or (void*) to function pointer as safe
commit f951de9a3b3e88fbe8ebbde452aa22bd06da2cb3
Author: Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>
AuthorDate: Mon Oct 27 18:51:47 2025 +0000
Commit: Stefano Stabellini <stefano.stabellini@xxxxxxx>
CommitDate: Wed Dec 10 17:42:40 2025 -0800
misra: consider conversion from UL or (void*) to function pointer as safe
Rule 11.1 states as following: "Conversions shall not be performed
between a pointer to a function and any other type."
This deviation from Rule 11.1 relies on both ABI definitions and compiler
implementations supported by Xen. The System V x86_64 ABI and the AArch64
ELF ABI define consistent and compatible representations (i.e., having
the same size and memory layout) for (void *), unsigned long, and function
pointers, enabling safe conversions between these types without data loss
or corruption. Additionally, GCC and Clang, faithfully implement the ABI
specifications, ensuring that the generated machine code conforms to these
guarantees. Developers must note that this behavior is not universal and
depends on platform-specific ABIs and compiler implementations.
Configure Eclair to avoid reporting violations for conversions from
unsigned long or (void *) to a function pointer.
Add a compile-time assertion into the file 'xen/common/version.c' to
confirm this conversion compatibility across X86 and ARM platforms
(assuming this file is common for them).
References:
- System V x86_64 ABI:
https://gitlab.com/x86-psABIs/x86-64-ABI/-/jobs/artifacts/master/raw/x86-64-ABI/abi.pdf?job=build
- AArch64 ELF ABI: https://github.com/ARM-software/abi-aa/releases
- GCC: https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
- Clang: https://clang.llvm.org/docs/CrossCompilation.html
Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>
Reviewed-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
[stefano: remove special powerpc check]
Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx>
Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
docs/misra/deviations.rst | 8 +++++++-
docs/misra/rules.rst | 7 ++++++-
xen/common/version.c | 19 +++++++++++++++++++
4 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 7f3fd35a33..219ba6993b 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -375,6 +375,14 @@ constant expressions are required.\""
}
-doc_end
+-doc_begin="Conversion from unsigned long or (void *) to a function pointer
can restore full information, provided that the source type has enough bits to
restore it."
+-config=MC3A2.R11.1,casts+={safe,
+ "from(type(canonical(builtin(unsigned long)||pointer(builtin(void)))))
+ &&to(type(canonical(__function_pointer_types)))
+ &&relation(definitely_preserves_value)"
+}
+-doc_end
+
-doc_begin="The conversion from a function pointer to a boolean has a
well-known semantics that do not lead to unexpected behaviour."
-config=MC3A2.R11.1,casts+={safe,
"from(type(canonical(__function_pointer_types)))
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 3271317206..b3431ef24e 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -366,11 +366,17 @@ Deviations related to MISRA C:2012 Rules:
- Tagged as `safe` for ECLAIR.
* - R11.1
- - The conversion from a function pointer to unsigned long or (void \*)
does
+ - The conversion from a function pointer to unsigned long or '(void *)'
does
not lose any information, provided that the target type has enough bits
to store it.
- Tagged as `safe` for ECLAIR.
+ * - R11.1
+ - Conversion from unsigned long or '(void *)' to a function pointer can
+ restore full information, provided that the source type has enough bits
+ to restore it.
+ - Tagged as `safe` for ECLAIR.
+
* - R11.1
- The conversion from a function pointer to a boolean has a well-known
semantics that do not lead to unexpected behaviour.
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 4388010ec9..4e94251887 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -431,7 +431,12 @@ maintainers if you want to suggest a change.
- All conversions to integer types are permitted if the destination
type has enough bits to hold the entire value. Conversions to bool
and void* are permitted. Conversions from 'void noreturn (*)(...)'
- to 'void (*)(...)' are permitted.
+ to 'void (*)(...)' are permitted. Conversions from unsigned long or
+ '(void *)' to a function pointer are permitted.
+ Example::
+
+ unsigned long func_addr = (unsigned long)&some_function;
+ void (*restored_func)(void) = (void (*)(void))func_addr;
* - `Rule 11.2
<https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_02.c>`_
- Required
diff --git a/xen/common/version.c b/xen/common/version.c
index 553b97ba9b..80e7a9b981 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -217,6 +217,25 @@ void __init xen_build_init(void)
#endif /* CONFIG_X86 */
}
#endif /* BUILD_ID */
+
+/*
+ * This assertion checks compatibility between 'unsigned long', 'void *',
+ * and function pointers. This is true for most supported architectures,
+ * including X86 (x86_64) and ARM (arm, aarch64).
+ *
+ * For more context on architecture-specific preprocessor guards, see
+ * docs/misc/C-language-toolchain.rst.
+ *
+ * If porting Xen to a new architecture where this compatibility does not hold,
+ * exclude that architecture from these checks and provide suitable commentary
+ * and/or alternative checks as appropriate.
+ */
+static void __init __maybe_unused build_assertions(void)
+{
+ BUILD_BUG_ON(sizeof(unsigned long) != sizeof(void (*)(void)));
+ BUILD_BUG_ON(sizeof(void *) != sizeof(void (*)(void)));
+}
+
/*
* Local variables:
* mode: C
--
generated by git-patchbot for /home/xen/git/xen.git#master
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |