From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id RY6PD1KmqWIGUAIAWB0awg (envelope-from ) for ; Wed, 15 Jun 2022 05:28:50 -0400 Received: by simark.ca (Postfix, from userid 112) id 2B6E51E224; Wed, 15 Jun 2022 05:28:50 -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=gHM+eBz2; 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=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.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 A5D531E15D for ; Wed, 15 Jun 2022 05:28:49 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C180D3856265 for ; Wed, 15 Jun 2022 09:28:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C180D3856265 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1655285327; bh=aGLb0m+FVvCd0xj2QjTeya8K72dstT94Oz/4H0RFpGs=; 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=gHM+eBz20MMq6Nj1g3FH9cjkNTCHsw+O1ojhRn1l1D6dD/8IUJ2GvXVHMTEE73sM0 HFCtL/UX1HMCxXIye6J0gV80ExwSIDaoPNwxWRY2212zdrZdDa4mwB7mOOuxB5UYX5 O+Lebi5KoLNfGG0Ol2cycsXIeJKJx17ESjc3iQU8= 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 To: Luis Machado , 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-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 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.