On 2025-08-14 21:44, Andrew Cooper wrote:
On 14/08/2025 8:37 pm, Nicola Vetrini wrote:
On 2025-08-14 13:47, Andrew Cooper wrote:
On 14/08/2025 12:44 pm, Jan Beulich wrote:
On 14.08.2025 13:42, Andrew Cooper wrote:
On 14/08/2025 12:20 pm, Jan Beulich wrote:
On 08.08.2025 22:23, Andrew Cooper wrote:
--- a/xen/arch/x86/include/asm/x86-defns.h
+++ b/xen/arch/x86/include/asm/x86-defns.h
@@ -75,6 +75,7 @@
#define X86_CR4_PKE 0x00400000 /* enable PKE */
#define X86_CR4_CET 0x00800000 /* Control-flow
Enforcement Technology */
#define X86_CR4_PKS 0x01000000 /* Protection Key
Supervisor */
+#define X86_CR4_FRED 0x100000000 /* Fast Return and Event
Delivery */
... a UL suffix added here for Misra.
I was surprised, but Eclair is entirely fine with this.
And there is a use of the identifier in a monitored C file?
Yes. traps-setup.c which definitely has not been added to an
exclusion
list.
Might look into it before the end of the week, if time allows. Is [1]
the right branch to look at?
[1]
https://gitlab.com/xen-project/hardware/xen-staging/-/commits/andrew/fred
Yes, although I am force pushing this with fixes as I find them.
In the latest run at the time of writing, I had one trivial R8.4
violation to fix, and all other clean rules came up fine. I expect the
next run to be clean.
One thing that might be relevant, IIRC it's implementation defined
behaviour what happens to constants which are wider than int to begin
with.
See my other reply in this thread; the rule is concerned with the type
of the constant present after preprocessing, which is defined in C99
6.4.4.1.5 . As such, I'm not sure what you're hinting at regarding IDB
here. Of course I might be wrong.
~Andrew
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
