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 F0BDF385735A for ; Wed, 15 Jun 2022 10:46:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F0BDF385735A 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 25FAjt1m025377; Wed, 15 Jun 2022 12:46:44 +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 3gp2tyqrg5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Jun 2022 12:46:44 +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 DE6FE10002A; Wed, 15 Jun 2022 12:46:41 +0200 (CEST) Received: from Webmail-eu.st.com (shfdag1node2.st.com [10.75.129.70]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id D1CA72194F7; Wed, 15 Jun 2022 12:46:41 +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 12:46:39 +0200 Date: Wed, 15 Jun 2022 12:46:38 +0200 From: Yvan Roux To: Luis Machado , CC: Torbjorn SVENSSON Subject: Re: [PATCH 2/3] gdb/arm: Track msp and psp Message-ID: <20220615104638.GD28091@gnbcxd0114.gnb.st.com> 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> <296a457a-9c4e-b900-86b5-13a8171a72ed@foss.st.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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=-10.2 required=5.0 tests=BAYES_00, BODY_8BITS, 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 10:46:50 -0000 On Wed, Jun 15, 2022 at 11:15:25AM +0100, Luis Machado wrote: > On 6/15/22 10:46, Torbjorn SVENSSON wrote: > > > > > > 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. > > Thanks for the explanation. Yvan, would you please add this to the commit message as well? > > Otherwise, this series is OK. Sure, Thanks Luis. -- Y.