Hard fault w/ GCC 14 on RP2040

[agesome]

Hi. When building Zephyr with GCC 14.1.0 (arch linux package), it seems that on startup, z_thread_entry is called with entry = NULL, when normally it would = _main, which leads to a fault.

zephyr/lib/os/thread_entry.c

Line 48 in 4d0a8c1

entry(p1, p2, p3);

If we break in arch_switch_to_main_thread, it looks like this, _main (which is passed to z_thread_entry as entry) is OK:

#0  arch_switch_to_main_thread (main_thread=main_thread@entry=0x20020a50 <z_main_thread>, 
    stack_ptr=stack_ptr@entry=0x20033440 "\356\242^i\205\200\346", <incomplete sequence \333>..., 
    _main=_main@entry=0x1001e47d <bg_thread_main>) at /workspace/zephyr-workspace/zephyr/arch/arm/core/cortex_m/thread.c:575
#1  0x1001e63c in switch_to_main_thread (stack_ptr=0x20033440 "\356\242^i\205\200\346", <incomplete sequence \333>...)
    at /workspace/zephyr-workspace/zephyr/kernel/init.c:585
#2  z_cstart () at /workspace/zephyr-workspace/zephyr/kernel/init.c:684
#3  0x10002390 in z_prep_c () at /workspace/zephyr-workspace/zephyr/arch/arm/core/cortex_m/prep_c.c:196
#4  0x100021f4 in z_arm_reset () at /workspace/zephyr-workspace/zephyr/arch/arm/core/cortex_m/reset.S:169

but if we then break in z_thread_entry, it looks as if arch_switch_to_main_thread had _main = 0

#0  z_thread_entry (entry=0x0, p1=0x0, p2=0x0, p3=0x0) at /workspace/zephyr-workspace/zephyr/lib/os/thread_entry.c:48
#1  0x100023d6 in arch_switch_to_main_thread (main_thread=0x0, stack_ptr=0x0, _main=0x0)
    at /workspace/zephyr-workspace/zephyr/arch/arm/core/cortex_m/thread.c:575
#2  0xc5d30d16 in ?? ()

After some experimenting, I fixed this by commenting

zephyr/arch/arm/core/cortex_m/thread.c

Line 593 in 4d0a8c1

CODE_UNREACHABLE;

With GCC 12 included in Zephyr SDK, this problem does not appear.

So at this point I'm not sure if it's some incompatible change 12->14, or a bug in 14. Any advice?

I also made a comparison of assembly on GCC 14 with/without CODE_UNREACHABLE and GCC 12: https://gist.github.com/agesome/bfc1e15b561df353fd5f340c0413e348

[fabiobaltieri]

Thanks @agesome, I converted this to and issue: #80542, those are triaged and monitored