Hello, Playing with sample STM32 code on a board with Cortex-M33 and Security extension (STM32L552) I put a breakpoint in SysTick_Handler from NUCLEO-L552ZE-Q/Examples/GTZC/GTZC_TZSC_MPCBB_TrustZone/NonSecure/Src/stm32l5xx_it.c:132 When I ask for a backtrace, with GDB trunk I get: (gdb) bt #0 SysTick_Handler () at [...]/stm32l5xx_it.c:132 Backtrace stopped: Cannot access memory at address 0xd034f8d6 If I apply the patches I posted recently to add support for FNC_RETURN on such devices (https://sourceware.org/pipermail/gdb-patches/2022-January/185127.html), I get: (gdb) bt #0 SysTick_Handler () at [...]/stm32l5xx_it.c:132 #1 <signal handler called> #2 0x00000000 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) which only partially better ;-) When I single-step in gdb's arm_m_exception_cache, I notice that sp = get_frame_register_unsigned (this_frame, ARM_SP_REGNUM); returns 0x2002ff78, but later in the same function unwound_sp = arm_cache_get_prev_sp (cache, tdep); returns 0x2002ff70. Since the breakpoint is set after the prologue, I think I might need to add something like arm_scan_prologue (this_frame, cache); but this leads to a crash. Looking into arm_scan_prologue, I was surprised to see that arm_frame_is_thumb returns false although the processor is Cortex-M (so thumb-only). This is because t_bit == 0x1000000 and cpsr == 0xf, which is surprising? I have access to the board only until tomorrow, so I'm dumping my findings here in case I can get help very quickly or someone else picks up the problem later.
Hi Christophe. Has this been addressed?
Yes I think that was fixed earlier this year. I think Torbjörn can confirm.
(In reply to Christophe Lyon from comment #2) > Yes I think that was fixed earlier this year. I think Torbjörn can confirm. I think that this issue has been resolved, but I don't remember to has seen it myself. Maybe we can resolve it and if we see something similar in the future, we can address it then?
Sounds good. Please reopen if needed. Thanks!