From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by sourceware.org (Postfix) with ESMTPS id 25B903856265 for ; Wed, 15 Jun 2022 09:46:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 25B903856265 Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 25F6ntlU008421; Wed, 15 Jun 2022 11:46:24 +0200 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 3gp2uhfhvk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jun 2022 11:46:24 +0200 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 60C8C10002A; Wed, 15 Jun 2022 11:46:24 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node2.st.com [10.75.129.70]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 575D9216821; Wed, 15 Jun 2022 11:46:24 +0200 (CEST) Received: from [10.210.54.229] (10.210.54.229) by SHFDAG1NODE2.st.com (10.75.129.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Wed, 15 Jun 2022 11:46:23 +0200 Message-ID: <296a457a-9c4e-b900-86b5-13a8171a72ed@foss.st.com> Date: Wed, 15 Jun 2022 11:46:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 2/3] gdb/arm: Track msp and psp Content-Language: en-US To: Yvan Roux , Luis Machado , References: <20220614145606.GB12000@gnbcxd0114.gnb.st.com> <20220614150032.GD12000@gnbcxd0114.gnb.st.com> <65771da9-0ff9-170c-f682-337ae0296884@arm.com> <20220615092819.GB26132@gnbcxd0114.gnb.st.com> From: Torbjorn SVENSSON In-Reply-To: <20220615092819.GB26132@gnbcxd0114.gnb.st.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.210.54.229] X-ClientProxiedBy: SHFCAS1NODE1.st.com (10.75.129.72) To SHFDAG1NODE2.st.com (10.75.129.70) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.517,FMLib:17.11.64.514 definitions=2022-06-15_03,2022-06-13_01,2022-02-23_01 X-Spam-Status: No, score=-13.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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-List-Received-Date: Wed, 15 Jun 2022 09:46:29 -0000 On 2022-06-15 11:28, Yvan Roux wrote: > On Wed, Jun 15, 2022 at 09:57:22AM +0100, Luis Machado wrote: >> On 6/14/22 16:00, Yvan Roux wrote: >>> For Arm Cortex-M33 with security extensions, there are 4 different >>> stack pointers (msp_s, msp_ns, psp_s, psp_ns). To be compatible >>> with earlier Cortex-M derivates, the msp and psp registers are >>> aliases for one of the 4 real stack pointer registers. >>> >>> These are the combinations that exist: >>> sp -> msp -> msp_s >>> sp -> msp -> msp_ns >>> sp -> psp -> psp_s >>> sp -> psp -> psp_ns >>> >>> This means that when the GDB client is to show the value of "msp", >>> the value should always be equal to either "msp_s" or "msp_ns". >>> Same goes for "psp". >>> >>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29121 >>> >>> Signed-off-by: Torbj�rn SVENSSON >>> Signed-off-by: Yvan Roux >>> --- >>> gdb/arm-tdep.c | 18 ++++++++++++++++++ >>> 1 file changed, 18 insertions(+) >>> >>> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c >>> index 1df57f5b5c8..e497dd1b3b8 100644 >>> --- a/gdb/arm-tdep.c >>> +++ b/gdb/arm-tdep.c >>> @@ -288,6 +288,8 @@ struct arm_prologue_cache >>> /* Active stack pointer. */ >>> int active_sp_regnum; >>> + int active_msp_regnum; >>> + int active_psp_regnum; >>> /* The frame base for this frame is just prev_sp - frame size. >>> FRAMESIZE is the distance from the frame pointer to the >>> @@ -345,11 +347,23 @@ arm_cache_init (struct arm_prologue_cache *cache, struct frame_info *frame) >>> if (tdep->have_sec_ext) >>> { >>> + CORE_ADDR msp_val = get_frame_register_unsigned (frame, tdep->m_profile_msp_regnum); >>> + CORE_ADDR psp_val = get_frame_register_unsigned (frame, tdep->m_profile_psp_regnum); >>> + >>> arm_cache_init_sp (tdep->m_profile_msp_s_regnum, &cache->msp_s, cache, frame); >>> arm_cache_init_sp (tdep->m_profile_psp_s_regnum, &cache->psp_s, cache, frame); >>> arm_cache_init_sp (tdep->m_profile_msp_ns_regnum, &cache->msp_ns, cache, frame); >>> arm_cache_init_sp (tdep->m_profile_psp_ns_regnum, &cache->psp_ns, cache, frame); >>> + if (msp_val == cache->msp_s) >>> + cache->active_msp_regnum = tdep->m_profile_msp_s_regnum; >>> + else if (msp_val == cache->msp_ns) >>> + cache->active_msp_regnum = tdep->m_profile_msp_ns_regnum; >>> + if (psp_val == cache->psp_s) >>> + cache->active_psp_regnum = tdep->m_profile_psp_s_regnum; >>> + else if (psp_val == cache->psp_ns) >>> + cache->active_psp_regnum = tdep->m_profile_psp_ns_regnum; >>> + >>> /* Use MSP_S as default stack pointer. */ >>> if (cache->active_sp_regnum == ARM_SP_REGNUM) >>> cache->active_sp_regnum = tdep->m_profile_msp_s_regnum; >>> @@ -384,6 +398,10 @@ arm_cache_get_sp_register (struct arm_prologue_cache *cache, >>> return cache->psp_s; >>> if (regnum == tdep->m_profile_psp_ns_regnum) >>> return cache->psp_ns; >>> + if (regnum == tdep->m_profile_msp_regnum) >>> + return arm_cache_get_sp_register (cache, tdep, cache->active_msp_regnum); >>> + if (regnum == tdep->m_profile_psp_regnum) >>> + return arm_cache_get_sp_register (cache, tdep, cache->active_psp_regnum); >>> } >>> else if (tdep->is_m) >>> { >> >> Just so I understand this correctly, the problem is that we're not keeping the aliases in sync >> all the time, so sp/msp/psp and the 4 other registers are going out-of-sync. >> >> Also, although SP will be either msp or psp, we can have distinct and valid msp/psp values, right? > > Yes that's it, it the info provided by Torbjorn in the BZ, we can see: > > #2 > info r > ... > sp 0x30017f30 0x30017f30 > ... > msp 0x30017f18 0x30017f18 > psp 0x0 0x0 > msp_ns 0x2002ffd8 0x2002ffd8 > psp_ns 0xfffffffc 0xfffffffc > msp_s 0x30017f18 0x30017f18 > psp_s 0x0 0x0 > > where msp is in sync with msp_s and psp with psp_s but SP value is different > To add a bit more context; GDB does not really use the register msp (or psp) internally, but they are part of the set of registers that are provided by the target.xml file. As a result, they will be part of the set of registers that is printed using the "info r" command. Without this particular patch, GDB will hit the assert in the bottom of the arm_cache_get_sp_register function. Regards, Torbjörn