From patchwork Fri Nov 18 15:52:49 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Torbjorn SVENSSON X-Patchwork-Id: 55310 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 558CE3852200 for ; Fri, 18 Nov 2022 15:54:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 558CE3852200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1668786886; bh=ToX3G2jsdEDdr0SSkf5e/T9CLnk7MgSoUmpLgmNFIyk=; h=To:CC:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=sgJIuhFlQP8ptM8G5qP0vJ/o5ViYXftkspruyzBi0qKYhWlAoPHFNBXeKgYj76gP3 Cg/A17NiP+SoUWLM4YPocXhgAT3kmPPa6tre8PF+5GuxaV6PkbjwvBu5Jl4Wux1pSE 1XlNRV9wyuqmJ/AkeDK8ZKi9ZzY/4Doyq8AcpJZY= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by sourceware.org (Postfix) with ESMTPS id 02A2D3854551 for ; Fri, 18 Nov 2022 15:53:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 02A2D3854551 Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AICNlWh025133; Fri, 18 Nov 2022 16:53:45 +0100 Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3kx0my4shm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Nov 2022 16:53:45 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 3CE35100038; Fri, 18 Nov 2022 16:53:40 +0100 (CET) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 35C5623C690; Fri, 18 Nov 2022 16:53:40 +0100 (CET) Received: from jkgcxl0002.jkg.st.com (10.210.54.218) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.6; Fri, 18 Nov 2022 16:53:39 +0100 To: CC: , , Subject: [PATCH 0/4] v2 gdb/arm: Fixes for Cortex-M stack unwinding Date: Fri, 18 Nov 2022 16:52:49 +0100 Message-ID: <20221118155252.113476-1-torbjorn.svensson@foss.st.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Originating-IP: [10.210.54.218] X-ClientProxiedBy: EQNCAS1NODE3.st.com (10.75.129.80) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-18_04,2022-11-18_01,2022-06-22_01 X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: =?utf-8?q?Torbj=C3=B6rn_SVENSSON_via_Gdb-patches?= From: Torbjorn SVENSSON Reply-To: =?utf-8?q?Torbj=C3=B6rn_SVENSSON?= Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" Hi, This patchset attempts to attack the issue reported in pr/29738. Based on my testing on a STM32L552 with TrustZone, it appears to work as expected, but I'd love to have another set of eyes on this! Most of the items reported can be seen using the GTZC example from ST: https://github.com/STMicroelectronics/STM32CubeL5/tree/master/Projects/NUCLEO-L552ZE-Q/Examples/GTZC/GTZC_TZSC_MPCBB_TrustZone I've manually verfied the register content by setting break points in * main * Error_Handler * SecureFault_Handler For the dwarf2 problem in pr/29738, I added 7-chained functions like below and placed a breakpoint at myfunc7: void myfunc7() { HAL_Delay(1); } ... void myfunc1() { HAL_Delay(1); myfunc2(); } For each breakpoint, I then used the below macros to print the registers. For each of the printed frames, I then manually checked if the values maked sense. define show_reg shell printf "%-8s " '$arg0' p/x $arg0 end define show_stacks shell echo shell echo -e "\x1b[35mContent at $arg0\x1b[0m" bt set $i = 0 while $i <= $arg1 f $i show_reg $lr show_reg $pc show_reg $sp show_reg $msp show_reg $msp_s show_reg $msp_ns show_reg $psp show_reg $psp_s show_reg $psp_ns shell echo set $i = $i + 1 end shell echo shell echo end The show_stacks macro takes 2 arguments, a description and the number of frames to print registers for. To show the registers for all the frames when at the Error_Handler breakpoint, I used: show_stacks "Error_Handler" 7 After talkning to Luis about the v1 series of these patches, we concluded that a generic way to store the data needed by the prev_register function was better than trying to squeze the logic into the _init function. Kind regards, Torbjörn