Printing u32 on 32-bit and 64-bit without cast

[Paul Menzel]

Dear coreboot folks,

There is no common length modifier for u32 for “32-bit and 64-bit”. 
Currently, I am running into problems building 
`src/cpu/x86/smm/smm_module_loader.c:415:42` with 
`x86_64-linux-gnu-gcc-10 -m32` [1].

printk(BIOS_DEBUG, "%s: stack_end = 0x%lx\n", __func__, 
stub_params->stack_top - total_stack_size);

Using `PRIx32` fixes the build with 64-bit but now it fails with 32-bit, 
as commit 3a323808 (include, lib: Add <inttypes.h> printf macros) [2] adds

src/include/inttypes.h:#define PRIx32  "x"

which is dependent on the architecture(?), and is not the right length 
modifier for u32 on 32-bit.

Is there an elegant way around it besides casting the values? Do we need 
specific headers for 32-bit or 64-bit?

Kind regards,

Paul

[1]: https://review.coreboot.org/c/coreboot/+/54343
[2]: https://review.coreboot.org/c/coreboot/+/33823

[Peter Stuge]

Hi Paul,

Paul Menzel wrote:
> printk(BIOS_DEBUG, "%s: stack_end = 0x%lx\n", __func__, stub_params->stack_top - total_stack_size);
>
> Using `PRIx32` fixes the build with 64-bit but now it fails with 32-bit, 
> as commit 3a323808 (include, lib: Add <inttypes.h> printf macros) [2] adds
>  src/include/inttypes.h:#define PRIx32  "x"
>
> which is dependent on the architecture(?),

Isn't the purpose of those PRI defines that they are always correct?

If they aren't correct in some cases then they should probably just
be fixed? I guess that -m32 with a x86_64 toolchain may need to be
detected differently than a i686 toolchain.
> and is not the right length modifier for u32 on 32-bit.

Huh? What is?

AFAIK %x is fine for a 32-bit value, both with i686 and x86_64.

%lx is always for a (signed or unsigned) long value, which obviously
differs between i686 and x86_64.

%llx is always for a long long value, which AFAIK is 64-bit on all
systems, but sure, not neccessarily guaranteed to be.
> Is there an elegant way around it besides casting the values?

If the PRI-defines are wrong in some cases they should be fixed.

Code explicitly using a l or ll length modifier for fixed-size values
is incorrect and should also be fixed.
> Do we need specific headers for 32-bit or 64-bit?

No, but maybe more cases in the existing header.

//Peter