Re: [PATCH] tools/tests: Fix paging-mempool xen_pfn_t format strings

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 21/05/2026 4:30 pm, Jan Beulich wrote:
> On 21.05.2026 17:23, Luca Fancellu wrote:
>> xen_pfn_t is not an unsigned long on all architectures. In particular,
>> Arm32 builds see it as a 64-bit type, so printing it with %lx triggers
>> a -Werror=format build failure.
>>
>> Use PRI_xen_pfn for the GFN diagnostics instead.
>>
>> Fixes: 66c982a5d3614 ("tests/paging-mempool: Extend to test P2M relocation")
>> Signed-off-by: Luca Fancellu <luca.fancellu@xxxxxxx>
> This looks okay, but while we're here ...
>
>> --- a/tools/tests/paging-mempool/test-paging-mempool.c
>> +++ b/tools/tests/paging-mempool/test-paging-mempool.c
>> @@ -208,7 +208,7 @@ static int check_guest_marks(xen_pfn_t gfn, uint32_t 
>> mark_start, size_t count)
>>          if ( errs[i] )
>>          {
>>              rc = -1;
>> -            fail("    Fail: check mark unable to map gfn %05lx: %d\n",
>> +            fail("    Fail: check mark unable to map gfn %05"PRI_xen_pfn": 
>> %d\n",
>>                   gfns[i], errs[i]);
>>              continue;
>>          }
>> @@ -216,7 +216,7 @@ static int check_guest_marks(xen_pfn_t gfn, uint32_t 
>> mark_start, size_t count)
>>          if ( *mark == exp )
>>              continue;
>>  
>> -        fail("    Fail: check mark: gfn %05lx expecting %08x (%u), got %08x 
>> (%u)\n",
>> +        fail("    Fail: check mark: gfn %05"PRI_xen_pfn" expecting %08x 
>> (%u), got %08x (%u)\n",
>>                 gfns[i], exp, ~exp, *mark, ~*mark);
> ... aren't the two ~ wrong here? The message looks to aim at printing the
> same value as hex and dec.

That's intentional.

The mark is the GFN number, but inverted so gfn 0 doesn't get 0.  But
this also makes it awkward to read when something goes wrong.

>From the failing example in the original commit:

      Fail: check mark unable to map 003c1: -22
      ...
      Fail: check mark unable to map 003df: -22
      Fail: check mark: gfn 003e0 expecting fffffe20 (479), got fffffe3f (448)

This presents the raw mark, and the useful-form decimal.

~Andrew