From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1FDDE3858C50; Thu, 5 May 2022 16:20:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1FDDE3858C50 From: "torbjorn.svensson at st dot com" 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: tdep X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: torbjorn.svensson at st dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2022 16:20:07 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29121 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=3D14091&action=3Ded= it Track msp and psp for targets with security ext For Arm Cortex-M33 with trustzone enabled, the stack unwinding does not wor= k 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_Trust= Zone with the small modification to enable TIM2 and put the ISR in secure contex= t. 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=3D0x3000002c ) 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-L5= 52ZE-Q/Examples/GTZC/GTZC_TZSC_MPCBB_TrustZone/Secure/Src/stm32l5xx_it.c:270 #2 #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 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=