[PATCH 0/4] address most remaining rule 11.1 violations

[PATCH 0/4] address most remaining rule 11.1 violations

[Jan Beulich]

"Conversions shall not be performed between a pointer to a function and
any other type"

The few ones left (x86_64-allcode:1, x86_64-amd:1, ARM64-allcode:2,
ARM64-amd:0) likely need dealing with by tweaking patch 3; see remarks
there.

1: x86/domain: address Misra rule 11.1 violation in reset_stack_and_call_ind()
2: Eclair: relax long <-> function-pointer conversion deviation
3: Eclair: relax "noreturn" function-pointer conversion deviation
4: x86/kexec: address Misra rule 11.1 violation in machine_kexec_load()

Jan

[PATCH 1/4] x86/domain: address Misra rule 11.1 violation in reset_stack_and_call_ind()

[Jan Beulich]

Eclair dislikes both sides of the comparison to differ in noreturn
attributes, thus deeming this a violation of "Conversions shall not be
performed between a pointer to a function and any other type". Since gcc
doesn't permit use of "noreturn" types used in a typecast, resort to
typeof().

No functional change intended.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
Really Eclair's diagnosis is misleading here, and not only because of the
missing "noreturn" there, making both sides be identical: There are no
implicit conversions performed on this kind of pointer operands of an
equality expression. A diagnosis of "comparison of pointers to different
types", along the lines of what compilers use, would be more to the point.

--- a/xen/arch/x86/include/asm/current.h
+++ b/xen/arch/x86/include/asm/current.h
@@ -208,7 +208,7 @@ unsigned long get_stack_dump_bottom (uns
 /* The constraint may only specify non-call-clobbered registers. */
 #define reset_stack_and_call_ind(fn)                                    \
     ({                                                                  \
-        (void)((fn) == (void (*)(void))NULL);                           \
+        (void)((fn) == (typeof(dom_xen->arch.ctxt_switch->tail))NULL);  \
         switch_stack_and_jump(fn, "INDIRECT_CALL %", "b");              \
     })
 

Re: [PATCH 1/4] x86/domain: address Misra rule 11.1 violation in reset_stack_and_call_ind()

[Nicola Vetrini]

On 2026-09-03 13:43, Jan Beulich wrote:
> Eclair dislikes both sides of the comparison to differ in noreturn
> attributes, thus deeming this a violation of "Conversions shall not be
> performed between a pointer to a function and any other type". Since 
> gcc
> doesn't permit use of "noreturn" types used in a typecast, resort to
> typeof().
> 
> No functional change intended.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

> ---
> Really Eclair's diagnosis is misleading here, and not only because of 
> the
> missing "noreturn" there, making both sides be identical: There are no
> implicit conversions performed on this kind of pointer operands of an
> equality expression. A diagnosis of "comparison of pointers to 
> different
> types", along the lines of what compilers use, would be more to the 
> point.
> 

The point here is that the types are not identical, if you consider 
noreturn as part of the function type (as clang does) or not (as GCC 
does). This is the reason why we err on the side of caution and diagnose 
this, and it's not likely to change in the near future. Perhaps we could 
make the violation message more explicit about the motivation of the 
mismatch.

> --- a/xen/arch/x86/include/asm/current.h
> +++ b/xen/arch/x86/include/asm/current.h
> @@ -208,7 +208,7 @@ unsigned long get_stack_dump_bottom (uns
>  /* The constraint may only specify non-call-clobbered registers. */
>  #define reset_stack_and_call_ind(fn)                                   
>  \
>      ({                                                                 
>  \
> -        (void)((fn) == (void (*)(void))NULL);                          
>  \
> +        (void)((fn) == (typeof(dom_xen->arch.ctxt_switch->tail))NULL); 
>  \
>          switch_stack_and_jump(fn, "INDIRECT_CALL %", "b");             
>  \
>      })

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

[PATCH 2/4] Eclair: relax long <-> function-pointer conversion deviation

[Jan Beulich]

What is true for unsigned long is also true for plain/signed long, thus
also taking care of two instances of __x86_return_thunk() being cast to
long.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -368,17 +368,17 @@ constant expressions are required.\""
 # Series 11
 #
 
--doc_begin="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."
+-doc_begin="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."
 -config=MC3A2.R11.1,casts+={safe,
   "from(type(canonical(__function_pointer_types)))
-   &&to(type(canonical(builtin(unsigned long)||pointer(builtin(void)))))
+   &&to(type(canonical(builtin(long)||builtin(unsigned long)||pointer(builtin(void)))))
    &&relation(definitely_preserves_value)"
 }
 -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."
+-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)))))
+  "from(type(canonical(builtin(long)||builtin(unsigned long)||pointer(builtin(void)))))
    &&to(type(canonical(__function_pointer_types)))
    &&relation(definitely_preserves_value)"
 }
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -432,8 +432,8 @@ maintainers if you want to suggest a cha
      - 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. Conversions from unsigned long or
-       '(void *)' to a function pointer 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;

Re: [PATCH 2/4] Eclair: relax long <-> function-pointer conversion deviation

[Nicola Vetrini]

On 2026-09-03 13:43, Jan Beulich wrote:
> What is true for unsigned long is also true for plain/signed long, thus
> also taking care of two instances of __x86_return_thunk() being cast to
> long.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Some nits below:

> 
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -368,17 +368,17 @@ constant expressions are required.\""
>  # Series 11
>  #
> 
> --doc_begin="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."
> +-doc_begin="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."
>  -config=MC3A2.R11.1,casts+={safe,
>    "from(type(canonical(__function_pointer_types)))
> -   &&to(type(canonical(builtin(unsigned 
> long)||pointer(builtin(void)))))
> +   &&to(type(canonical(builtin(long)||builtin(unsigned 
> long)||pointer(builtin(void)))))
>     &&relation(definitely_preserves_value)"
>  }

could be canonical(builtin(long||unsigned long))||pointer(builtin(void))

>  -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."
> +-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)))))
> +  "from(type(canonical(builtin(long)||builtin(unsigned 
> long)||pointer(builtin(void)))))
>     &&to(type(canonical(__function_pointer_types)))
>     &&relation(definitely_preserves_value)"
>  }

Same as above

> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -432,8 +432,8 @@ maintainers if you want to suggest a cha
>       - 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. Conversions from unsigned 
> long or
> -       '(void *)' to a function pointer 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;

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

[PATCH 3/4] Eclair: relax "noreturn" function-pointer conversion deviation

[Jan Beulich]

Like misra/rules.rst says, function arguments other than "void *" are okay
as well.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
I can't explain why this covers the violation in mce.c:mce_callbacks'es
initializer, but not the one in mce.c:default_handler's.

As a result of 6852334f8416 ("Arm/GIC: add noreturn in a few more
places"), vgic_v2_lpi_to_pending() and vgic_v2_lpi_get_priority() (both
returning non-void) would also need covering. (As said in a remark there,
non-void together with noreturn is somewhat odd.)

Really before and after this change there's no checking that parameter and
return types actually match. I have no clue how one would express such
checks.

--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -391,11 +391,11 @@ constant expressions are required.\""
 }
 -doc_end
 
--doc_begin="The conversion from 'void noreturn (*)(void *)' to 'void (*)(void *)' is safe
+-doc_begin="The conversion from 'void noreturn (*)(...)' to 'void (*)(...)' is safe
 because the semantics of the 'noreturn' attribute do not alter the calling convention or behavior of the resulting code."
 -config=MC3A2.R11.1,casts+={safe,
-  "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))&&all_param(1, pointer(builtin(void)))))))&&from(expr(skip(!syntactic(),
-   ref(property(noreturn)))))"} 
+  "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))))))&&from(expr(skip(!syntactic(),ref(property(noreturn)))))"
+}
 -doc_end
 
 -doc_begin="The conversion from a pointer to an incomplete type to unsigned long does not lose any information, provided that the target type has enough bits to store it."

Re: [PATCH 3/4] Eclair: relax "noreturn" function-pointer conversion deviation

[Nicola Vetrini]

On 2026-09-03 13:44, Jan Beulich wrote:
> Like misra/rules.rst says, function arguments other than "void *" are 
> okay
> as well.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> ---
> I can't explain why this covers the violation in mce.c:mce_callbacks'es
> initializer, but not the one in mce.c:default_handler's.
> 

Possibly differing attributes (e.g. cf_check vs section attributes)? 
Just a guess that would need to be tested, though.

> As a result of 6852334f8416 ("Arm/GIC: add noreturn in a few more
> places"), vgic_v2_lpi_to_pending() and vgic_v2_lpi_get_priority() (both
> returning non-void) would also need covering. (As said in a remark 
> there,
> non-void together with noreturn is somewhat odd.)
> 

Indeed

> Really before and after this change there's no checking that parameter 
> and
> return types actually match. I have no clue how one would express such
> checks.

The presence of a bitcast indicates that the two types do not match 
exactly. Typically function attributes are not relevant towards 
determining a type difference, but different compilers may model 
non-standard features differently (rightly so), in such a way that some 
make a difference in the AST, and others do not.

To check for compatibility of function pointers I would try activating 
service STD.funptrcv, which essentially mirrors 
-Wincompatible-pointer-types:

caution for rule STD.funptrcv: (rule) A pointer is used to call a 
function whose type is not compatible with the pointed-to type. 
(untagged)
p.c:8.8-8.8: Loc #1 [culprit: implicit cast converts from `void(*)(int)' 
to `__typeof__(@EXPR@)*' (that is `void(*)(void)')]
   qq = m;
        ^
p.c: In function ‘h’:
p.c:8:6: error: assignment to ‘void (*)(void)’ from incompatible pointer 
type ‘void (*)(int)’ [-Wincompatible-pointer-types]
     8 |   qq = m;
       |      ^
p.c:3:6: note: ‘m’ declared here
     3 | void m(int x);
       |      ^


> 
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -391,11 +391,11 @@ constant expressions are required.\""
>  }
>  -doc_end
> 
> --doc_begin="The conversion from 'void noreturn (*)(void *)' to 'void 
> (*)(void *)' is safe
> +-doc_begin="The conversion from 'void noreturn (*)(...)' to 'void 
> (*)(...)' is safe
>  because the semantics of the 'noreturn' attribute do not alter the 
> calling convention or behavior of the resulting code."
>  -config=MC3A2.R11.1,casts+={safe,
> -  
> "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))&&all_param(1, 
> pointer(builtin(void)))))))&&from(expr(skip(!syntactic(),
> -   ref(property(noreturn)))))"}
> +  
> "kind(bitcast)&&to(type(pointer(inner(return(builtin(void))))))&&from(expr(skip(!syntactic(),ref(property(noreturn)))))"
> +}
>  -doc_end
> 
>  -doc_begin="The conversion from a pointer to an incomplete type to 
> unsigned long does not lose any information, provided that the target 
> type has enough bits to store it."

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

[PATCH 4/4] x86/kexec: address Misra rule 11.1 violation in machine_kexec_load()

[Jan Beulich]

Misra rule 11.1 demands no conversion to different types at all. We
deviate conversions to long, unsigned long, and void *, though - leverage
that deviation here.

No functional change intended.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/machine_kexec.c
+++ b/xen/arch/x86/machine_kexec.c
@@ -121,7 +121,8 @@ int machine_kexec_load(struct kexec_imag
     }
 
     code_page = __map_domain_page(image->control_code_page);
-    memcpy(code_page, kexec_reloc, kexec_reloc_end - (char *)kexec_reloc);
+    memcpy(code_page, kexec_reloc,
+           kexec_reloc_end - (const char *)(unsigned long)kexec_reloc);
     unmap_domain_page(code_page);
 
     /*

Re: [PATCH 4/4] x86/kexec: address Misra rule 11.1 violation in machine_kexec_load()

[Nicola Vetrini]

On 2026-09-03 13:44, Jan Beulich wrote:
> Misra rule 11.1 demands no conversion to different types at all. We
> deviate conversions to long, unsigned long, and void *, though - 
> leverage
> that deviation here.
> 
> No functional change intended.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

> 
> --- a/xen/arch/x86/machine_kexec.c
> +++ b/xen/arch/x86/machine_kexec.c
> @@ -121,7 +121,8 @@ int machine_kexec_load(struct kexec_imag
>      }
> 
>      code_page = __map_domain_page(image->control_code_page);
> -    memcpy(code_page, kexec_reloc, kexec_reloc_end - (char 
> *)kexec_reloc);
> +    memcpy(code_page, kexec_reloc,
> +           kexec_reloc_end - (const char *)(unsigned 
> long)kexec_reloc);
>      unmap_domain_page(code_page);
> 
>      /*

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253

Re: [PATCH 0/4] address most remaining rule 11.1 violations

[Jan Beulich]

On 03.09.2026 13:42, Jan Beulich wrote:
> "Conversions shall not be performed between a pointer to a function and
> any other type"
> 
> The few ones left (x86_64-allcode:1, x86_64-amd:1, ARM64-allcode:2,
> ARM64-amd:0) likely need dealing with by tweaking patch 3; see remarks
> there.

As per [1], that is.

Jan

[1] https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2816360844