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 756AB3856DFF for ; Wed, 15 Jun 2022 09:28:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 756AB3856DFF Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 25F6ZH1c025353; Wed, 15 Jun 2022 11:28:23 +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 3gp2tyq6ds-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jun 2022 11:28:23 +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 9D51410002A; Wed, 15 Jun 2022 11:28:22 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node2.st.com [10.75.129.70]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id 93ADD214D3A; Wed, 15 Jun 2022 11:28:22 +0200 (CEST) Received: from gnbcxd0114.gnb.st.com (10.129.178.234) 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:28:20 +0200 Date: Wed, 15 Jun 2022 11:28:19 +0200 From: Yvan Roux To: Luis Machado , CC: Torbjorn SVENSSON Subject: Re: [PATCH 2/3] gdb/arm: Track msp and psp Message-ID: <20220615092819.GB26132@gnbcxd0114.gnb.st.com> References: <20220614145606.GB12000@gnbcxd0114.gnb.st.com> <20220614150032.GD12000@gnbcxd0114.gnb.st.com> <65771da9-0ff9-170c-f682-337ae0296884@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <65771da9-0ff9-170c-f682-337ae0296884@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Originating-IP: [10.129.178.234] 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=-11.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, GIT_PATCH_0, 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:28:29 -0000 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 -- Y.