backtrace of GDB is not working normally on a Cortex-M55 soc using Zephyr-SDK-v16.8

[ZhiyuanTang17]

Backgroud：

I am trying porting a new soc (cortex-m55 without security extension) on Zephyr v3.7 LTS with zephyr-sdk-16.8 as toolchain.

### Issue：
When I want to test the west debug feature, I found that the backtrace call chain is incomplete, with the call chain missing after .

How to reproduce：

I produce a simple hardfault case in hello_world project, looks like:

In the another series soc (based on cortex-m33), the west debug and backtrace of gdb looks normal:

#0  arch_system_halt (reason=19) at C:/ACODE/workspace/zephyr/kernel/fatal.c:30
#1  0x04033374 in k_sys_fatal_error_handler (reason=<optimized out>, esf=<optimized out>) at C:/ACODE/workspace/zephyr/kernel/fatal.c:44
#2  0x04030408 in z_fatal_error (reason=<optimized out>, esf=<optimized out>) at C:/ACODE/workspace/zephyr/kernel/fatal.c:119
#3  0x04032e76 in z_arm_fatal_error (reason=reason@entry=19, esf=esf@entry=0x102848 <z_interrupt_stacks+1920>) at C:/ACODE/workspace/zephyr/arch/arm/core/fatal.c:86
#4  0x0402fba8 in z_arm_fault (msp=<optimized out>, psp=<optimized out>, exc_return=<optimized out>, callee_regs=<optimized out>) at C:/ACODE/workspace/zephyr/arch/arm/core/cortex_m/fault.c:1157
#5  0x0402fc7c in z_arm_usage_fault () at C:/ACODE/workspace/zephyr/arch/arm/core/cortex_m\fault_s.S:102
#6  <signal handler called>
#7  0x0402f518 in func3 () at C:/ACODE/workspace/zephyr/samples/hello_world/src/main.c:16
#8  func2 () at C:/ACODE/workspace/zephyr/samples/hello_world/src/main.c:22
#9  func1 () at C:/ACODE/workspace/zephyr/samples/hello_world/src/main.c:28
#10 main () at C:/ACODE/workspace/zephyr/samples/hello_world/src/main.c:36  

But in this cortex-m55 based soc. the output is:

GDB backtrace

LOG:

I have also reproduced another assert case, the output looks similar:

My analysis：

I suspect that the determination of lr 0xffffffac as a normal frame in GDB is causing it to be unresolvable. However, after reviewing the GDB source code, I found that it can identify this value as a SIGTRAMP_FRAME.

gdb\arm-tdep.c:

Need help：

So Is there a debug version of Zephyr ARM GDB to print infomation of Frame Decorator that can help analyze this issue?
Or anyone can give some debugging ideas about this?

[ZhiyuanTang17]

It seems that zephyr-SDK-0.16.x use Binutils 2.38, which would categorize LR 0xffffffac as a normal stack:

I found that in zephyr-sdk-0.18.x would use Binutils 2.43 that fixed this issue:

When I build with v0.18.x-alpha on zephyr v3.7LTS, I got this error:

It seems that Zephyr-v3.7 is not compatible with the v0.18.x-alpha version.

So how do we fix this issue? Is there any chance we can support to categorize "0xffffffac" as sigtramp_stack on zephyr v3.7?

[stephanosio]

@ZhiyuanTang17 Thanks for the detailed bug report and analysis.

I found that in zephyr-sdk-0.18.x would use Binutils 2.43 that fixed this issue:

Have you tried isolating the commits that fixed this issue? If so, we could look into backporting (cherry-picking) these into the zephyr-gdb-12.1 branch used by the Zephyr SDK 0.16.x.

[ZhiyuanTang17]

@ZhiyuanTang17 Thanks for the detailed bug report and analysis.

I found that in zephyr-sdk-0.18.x would use Binutils 2.43 that fixed this issue:

Have you tried isolating the commits that fixed this issue? If so, we could look into backporting (cherry-picking) these into the zephyr-gdb-12.1 branch used by the Zephyr SDK 0.16.x.

@stephanosio 👍 My Zephyr is v3.7 LTS, so I cannot use v0.18.x to build my app, as I tried.

I think what I could do is to cherry-pick the fix on zephyr-gdb-12.1 branch and build the arm-zephyr-eabi of v0.16.x and to try if it is work. But I am not familiar with how to build the arm-zephyr-eabi, is there any guide for how to build?

Plus, I have tried arm gnu toolchain v14.2 and it doesnot have this issue.

thx

[stephanosio]

I think what I could do is to cherry-pick the fix on zephyr-gdb-12.1 branch and build the arm-zephyr-eabi of v0.16.x and to try if it is work. But I am not familiar with how to build the arm-zephyr-eabi, is there any guide for how to build?

You can try opening a PR to GCC zephyr-gdb-12.1 branch cherry-picking the fixes, and open a PR on sdk-ng side (targeting v0.16-branch) updating the gcc submodule to the GCC PR ref -- this will build arm-zephyr-eabi toolchain with the proposed fix which you can download.

See #996 for example.