From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id vFTgJa64qWLnUwIAWB0awg (envelope-from ) for ; Wed, 15 Jun 2022 06:47:10 -0400 Received: by simark.ca (Postfix, from userid 112) id 8C1531E224; Wed, 15 Jun 2022 06:47:10 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=DRVeyj5+; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id E4EA41E143 for ; Wed, 15 Jun 2022 06:47:09 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DB70438485AE for ; Wed, 15 Jun 2022 10:47:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB70438485AE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1655290028; bh=EHsuTDEYjVfpA0xQTMruVb+UiqZAQrzszOupId+S71E=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=DRVeyj5+MK0cJLIkUpEISDmU48lVD+cSSellk/aBJAQGu/yA7BxflHfXt1si1XIvx v3VbreGdGIppQqAUbFu6cTueyemeWFnuOeFm6ssojPPgkCChIV+i/KTRySnHv2B1Y7 Fi5RHzLcdPIX4wzFwR1IfR8YRG5QlF3TZ2OT4JCk= 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 To: Luis Machado , 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-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: , From: Yvan Roux via Gdb-patches Reply-To: Yvan Roux Cc: Torbjorn SVENSSON Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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.