Re: [PATCH 1/5] x86: Misra fixes for U/L suffixes

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

On 2025-12-11 00:48, Andrew Cooper wrote:
> On 10/12/2025 8:31 pm, Nicola Vetrini wrote:
>> On 2025-12-10 21:09, Nicola Vetrini wrote:
>>> On 2025-12-10 19:30, Andrew Cooper wrote:
>>>> diff --git a/xen/include/xen/elfstructs.h
>>>> b/xen/include/xen/elfstructs.h
>>>> index eb6b87a823a8..8770e7454672 100644
>>>> --- a/xen/include/xen/elfstructs.h
>>>> +++ b/xen/include/xen/elfstructs.h
>>>> @@ -360,7 +360,7 @@ typedef struct {
>>>>  } Elf64_Rela;
>>>> 
>>>>  #define    ELF64_R_SYM(info)    ((info) >> 32)
>>>> -#define    ELF64_R_TYPE(info)    ((info) & 0xFFFFFFFF)
>>>> +#define    ELF64_R_TYPE(info)    ((uint32_t)(info))
>> 
>> Actually I think this doesn't build:
>> 
>> arch/x86/livepatch.c: In function ‘arch_livepatch_perform_rela’:
>> ././include/xen/config.h:55:24: error: format ‘%lu’ expects argument
>> of type ‘long unsigned int’, but argument 3 has type ‘unsigned int’
>> [-Werror=format=]
>>    55 | #define XENLOG_ERR     "<0>"
>>       |                        ^~~~~
>> arch/x86/livepatch.c:332:20: note: in expansion of macro ‘XENLOG_ERR’
>>   332 |             printk(XENLOG_ERR LIVEPATCH "%s: Unhandled
>> relocation %lu\n",
>>       |                    ^~~~~~~~~~
>> arch/x86/livepatch.c:332:69: note: format string is defined here
>>   332 |             printk(XENLOG_ERR LIVEPATCH "%s: Unhandled
>> relocation %lu\n",
>>      
>> |                                                                  
>>  ~~^
>>      
>> |                                                                     
>> |
>>      
>> |                                                                    
>> long unsigned int
>>      
>> |                                                                   %u
>> 
>> the error location is a bit unclear, but the cast is the culprit
> 
> Yeah, I spotted that just as I heading out, and ran
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2207521982
> instead.
> 
> I've swapped back to using 0xFFFFFFFFU.  info ends up being long, and
> the result of the expression needs to stay that way.
> 
> However, looking at the report for that, I still missed one.  I've
> folded in this hunk too.
> 
> diff --git a/xen/arch/x86/pv/emulate.c b/xen/arch/x86/pv/emulate.c
> index 8c44dea12330..e741e686c1af 100644
> --- a/xen/arch/x86/pv/emulate.c
> +++ b/xen/arch/x86/pv/emulate.c
> @@ -37,7 +37,7 @@ int pv_emul_read_descriptor(unsigned int sel, const 
> struct vcpu *v,
>      if ( !(desc.b & _SEGMENT_L) )
>      {
>          *base = ((desc.a >> 16) + ((desc.b & 0xff) << 16) +
> -                 (desc.b & 0xff000000));
> +                 (desc.b & 0xff000000U));
>          *limit = (desc.a & 0xffff) | (desc.b & 0x000f0000);
>          if ( desc.b & _SEGMENT_G )
>              *limit = ((*limit + 1) << 12) - 1;
> 

Makes sense, feel free to retain my R-by with these two changes.

> 
> ~Andrew

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