public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "torbjorn.svensson at st dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug tdep/29121] New: Stack unwinding not working correctly for Arm Cortex-M33 with trustzone when the ISR is in a different context Date: Thu, 05 May 2022 16:20:06 +0000 [thread overview] Message-ID: <bug-29121-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=29121 Bug ID: 29121 Summary: Stack unwinding not working correctly for Arm Cortex-M33 with trustzone when the ISR is in a different context Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: tdep Assignee: unassigned at sourceware dot org Reporter: torbjorn.svensson at st dot com Target Milestone: --- Created attachment 14091 --> https://sourceware.org/bugzilla/attachment.cgi?id=14091&action=edit Track msp and psp for targets with security ext For Arm Cortex-M33 with trustzone enabled, the stack unwinding does not work as expected when a interrupt happens where the ISR is in secure context and the CPU is currently executing in non-secure context. Using the STM32 example NUCLEO-L552ZE-Q/Examples/GTZC/GTZC_TZSC_MPCBB_TrustZone with the small modification to enable TIM2 and put the ISR in secure context. Put a break point in the main() in non-secure context and run to this point. b stm32l5xx_hal_tim.c:3756 c bt #0 HAL_TIM_IRQHandler (htim=0x3000002c <htim2>) at C:/Users/foo/STM32Cube/Repository/STM32Cube_FW_L5_V1.3.1/Drivers/STM32L5xx_HAL_Driver/Src/stm32l5xx_hal_tim.c:3756 #1 0x0c00079a in TIM2_IRQHandler () at C:/Users/foo/STM32Cube/Repository/STM32Cube_FW_L5_V1.3.1/Projects/NUCLEO-L552ZE-Q/Examples/GTZC/GTZC_TZSC_MPCBB_TrustZone/Secure/Src/stm32l5xx_it.c:270 #2 <signal handler called> #3 Reset_Handler () at ../Application/Startup/startup_stm32l552zetxq.s:102 #4 0x0804026e in Reset_Handler () at ../Application/Startup/startup_stm32l552zetxq.s:99 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Running "info r" makes GDB assert on frame 3 and 4 in the list above. With the attached patch, the assert is not triggered, but I'm not sure if it's the correct fix for the issue. In addition to the assert, I also see that there is a mismatch between the stack pointers. For Cortex-M33 with trustzone, sp is an "alias" for one of msp or psp. msp is an "alias" for msp_s or msp_ns and psp is an "alias" for psp_s or psp_ns. f 2 #2 <signal handler called> info r r0 0x3000002c 805306412 r1 0x70 112 r2 0x200180a8 536969384 r3 0x0 0 r4 0x8040238 134480440 r5 0x8040238 134480440 r6 0x8040238 134480440 r7 0x2002fff8 537067512 r8 0x8040238 134480440 r9 0x8040238 134480440 r10 0x8040238 134480440 r11 0x8040238 134480440 r12 0x8040238 134480440 sp 0x30017f30 0x30017f30 lr 0xffffffb9 -71 pc 0xffffffb9 0xffffffb9 xpsr 0x8900003d -1996488643 fpscr 0x0 0 msp 0x30017f18 0x30017f18 psp 0x0 0x0 msp_ns 0x2002ffd8 0x2002ffd8 psp_ns 0xfffffffc 0xfffffffc msp_s 0x30017f18 0x30017f18 psp_s 0x0 0x0 primask 0x0 0 basepri 0x0 0 faultmask 0x0 0 control 0x0 0 msplim_s 0x0 0x0 psplim_s 0x0 0x0 msplim_ns 0x0 0x0 psplim_ns 0x0 0x0 primask_s 0x0 0 basepri_s 0x0 0 faultmask_s 0x0 0 control_s 0x0 0 primask_ns 0x0 0 basepri_ns 0x0 0 faultmask_ns 0x0 0 control_ns 0x0 0 As can be seen here, something has "updated" the sp to 0x30017f30, but that update should also be applied to msp and msp_s as they should be in sync in this case. In addition, not sure if it's related or not, the main() frame for the non-secure context is missing from the bt above. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2022-05-05 16:20 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-05 16:20 torbjorn.svensson at st dot com [this message] 2022-05-09 6:56 ` [Bug tdep/29121] " clyon at gcc dot gnu.org 2022-05-10 16:08 ` luis.machado at arm dot com 2022-05-31 8:45 ` luis.machado at arm dot com 2022-10-06 8:24 ` luis.machado at arm dot com 2022-10-06 9:35 ` torbjorn.svensson at st dot com 2022-11-02 12:04 ` luis.machado at arm dot com 2023-04-24 13:44 ` luis.machado at arm dot com 2023-04-24 18:26 ` torbjorn.svensson at foss dot st.com 2023-04-25 7:50 ` luis.machado at arm dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-29121-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).