unsynchronized newlib uintptr_t and PRIxPTR definition on xtensa

[andrewboie]

Describe the bug
This seems to only affect Xtensa, I can only reproduce this with qemu_xtensa.

This assertion:

/* Just like Z_MEM_VIRT_ADDR() but with type safety and assertions */
static inline void *z_mem_virt_addr(uintptr_t phys)
{
	__ASSERT((phys >= CONFIG_SRAM_BASE_ADDRESS) &&
		 (phys < (CONFIG_SRAM_BASE_ADDRESS +
			  (CONFIG_SRAM_SIZE * 1024UL))),
		 "physical address 0x%" PRIxPTR " not in RAM", phys);

	return (void *)Z_MEM_VIRT_ADDR(phys);
}

produces:

/home/apboie/projects/zephyr/zephyr/include/sys/mem_manage.h: In function 'z_mem_virt_addr':
/home/apboie/projects/zephyr/zephyr/include/sys/__assert.h:32:52: error: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'uintptr_t' {aka 'long unsigned int'} [-Werror=format=]
   32 | #define __ASSERT_MSG_INFO(fmt, ...) __ASSERT_PRINT("\t" fmt "\n", ##__VA_ARGS__)
      |                                                    ^~~~
/home/apboie/projects/zephyr/zephyr/include/sys/__assert.h:24:41: note: in definition of macro '__ASSERT_PRINT'
   24 | #define __ASSERT_PRINT(fmt, ...) printk(fmt, ##__VA_ARGS__)
      |                                         ^~~
/home/apboie/projects/zephyr/zephyr/include/sys/__assert.h:96:4: note: in expansion of macro '__ASSERT_MSG_INFO'
   96 |    __ASSERT_MSG_INFO(fmt, ##__VA_ARGS__);            \
      |    ^~~~~~~~~~~~~~~~~
/home/apboie/projects/zephyr/zephyr/include/sys/mem_manage.h:156:2: note: in expansion of macro '__ASSERT'
  156 |  __ASSERT((phys >= CONFIG_SRAM_BASE_ADDRESS) &&
      |  ^~~~~~~~
cc1: all warnings being treated as errors

Expected behavior
The definitions of uintptr_t and PRIxPTR (and really any PRI.PTR) are in sync such that you get the right printf code for it.

Impact
Ugly workaround to hard-cast everything to just unsigned long which I'd rather not do.

[dcpleung]

I tried it with the following code added in hello_world:

        uintptr_t ptr = 0xDEADBEEF;

        printk("Hello World! %s\n", CONFIG_BOARD);

        printk("0x%" PRIxPTR "\n", ptr);

        __ASSERT(0, "0x%" PRIxPTR "\n", ptr);

And it compiled and ran on qemu_xtensa:

*** Booting Zephyr OS build zephyr-v2.3.0-1204-g80c2a751ffb8  ***
Hello World! qemu_xtensa
0xdeadbeef
ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/samples/hello_world/src/main.c:20
	0xdeadbeef

@ WEST_TOPDIR/zephyr/lib/os/assert.c:45
QEMU: Terminated

[dcpleung]

But with newlib, PRIxPTR is x instead of lx. Need to look at SDK to see how it is being done.

[dcpleung]

Fixes by zephyrproject-rtos/sdk-ng#257, which requires a new SDK build.

[galak]

@dcpleung / @andrewboie what's the urgency of a toolchain SDK with this fix? Trying to see if we need a 0.11.5 or does this wait for 0.12.x.

[andrewboie]

@dcpleung / @andrewboie what's the urgency of a toolchain SDK with this fix? Trying to see if we need a 0.11.5 or does this wait for 0.12.x.

I worked around it for the code I was working on with some casts to unsigned long, unless somebody complains about that in #27001 this isn't urgent.

[dcpleung]

This will be fixed once the new SDK with newlib 3 is release.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[dcpleung]

Newer SDK is merged via #31230. So closing this...