From: Luis Machado <luis.machado@arm.com>
To: Torbjorn SVENSSON <torbjorn.svensson@st.com>,
Yvan ROUX - foss <yvan.roux@foss.st.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH 3/3] gdb/arm: Track msp and psp
Date: Thu, 19 May 2022 09:07:35 +0100 [thread overview]
Message-ID: <495624cf-b21d-45ca-d6f6-090276e89e9c@arm.com> (raw)
In-Reply-To: <AM6PR10MB219795B1BC2A9CD7FE9460CD81D19@AM6PR10MB2197.EURPRD10.PROD.OUTLOOK.COM>
On 5/18/22 20:18, Torbjorn SVENSSON wrote:
>
>
> ST Restricted
>
>
>> -----Original Message-----
>> From: Luis Machado <luis.machado@arm.com>
>> Sent: den 17 maj 2022 17:53
>> To: Yvan ROUX - foss <yvan.roux@foss.st.com>; gdb-
>> patches@sourceware.org
>> Cc: Torbjorn SVENSSON <torbjorn.svensson@st.com>
>> Subject: Re: [PATCH 3/3] gdb/arm: Track msp and psp
>>
>> On 5/16/22 15:00, Yvan Roux via Gdb-patches wrote:
>>> For Arm Cortex-M33 with security extensions, there are 4 different
>>> stacks pointers (msp_s, msp_ns, psp_s, psp_ns). To be compatible
>>
>> stacks -> stack
>>
>>> with earlier Cortex-M derivates, the msp and psp register are
>>
>> register -> registers
>>
>>> 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".
>>>
>>
>> As a general comment, we should include, in the commit message, the bug
>> ticket link related to this problem:
>>
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29121
>>
>>> Signed-off-by: Torbj�rn SVENSSON <torbjorn.svensson@st.com>
>>> Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
>>> ---
>>> gdb/arm-tdep.c | 18 ++++++++++++++++++
>>> 1 file changed, 18 insertions(+)
>>>
>>> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
>>> index 4aa277f5bc8..b9c35bcdae6 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;
>>
>> Is it possible to have 3 active SP registers at the same time? Are msp and psp
>> really needed here or are we just not doing a good
>> job of figuring out what SP maps to? (msp_s, msp_ns, psp_s, psp_ns)
>
> Only one is "active", but you can view them all at the same time.
> The problem without tracking msp and psp (without suffixes) is that a simple "info registers" will not have anything to show for these 2 registers:
>
That's fine, but the naming is incorrect and possibly misleading. My understanding is that there is only SP (the active stack pointer). Yes, we can track the values of
the other registers, but the code should make that clear.
> The following was executed in secure context of a Cortex-M33.
> info r
> r0 0x30000000 805306368
> r1 0x74 116
> r2 0x300000e8 805306600
> r3 0xc00021d 201327133
> r4 0x0 0
> r5 0x0 0
> r6 0x0 0
> r7 0x30017fe0 805404640
> r8 0xffffffff -1
> r9 0xffffffff -1
> r10 0xffffffff -1
> r11 0xffffffff -1
> r12 0xffffffff -1
> sp 0x30017fe0 0x30017fe0
> lr 0xc00ef57 201387863
> pc 0xc00dc6e 0xc00dc6e <main+6>
> xpsr 0x61000000 1627389952
> fpscr 0x0 0
> primask 0x0 0
> basepri 0x0 0
> faultmask 0x0 0
> control 0x0 0
> msp 0x30017fe0 0x30017fe0
> psp 0x0 0x0
> msp_ns 0x0 0x0
> psp_ns 0xfffffffc 0xfffffffc
> msp_s 0x30017fe0 0x30017fe0
> psp_s 0x0 0x0
> msplim_s 0x0 0x0
> psplim_s 0x0 0x0
> msplim_ns 0x0 0x0
> psplim_ns 0x0 0x0
> primask_s 0x0 0
> basepri_s 0x0 0
> faultmask_s 0x0 0
> control_s 0x0 0
> primask_ns 0x0 0
> basepri_ns 0x0 0
> faultmask_ns 0x0 0
> control_ns 0x0 0
>
>
> As the registers are listed, they need to be tracked, or do you see any other way to give the right value for the register?
The most important thing is for GDB to produce a correct stack trace. If it is not doing that properly, then it is failing to calculate the correct SP.
I don't particularly understand what tracking msp/psp has to do with calculating the correct SP here. Maybe I'm missing some context.
>
>
> Kind regards,
> Torbjörn
next prev parent reply other threads:[~2022-05-19 8:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-16 13:54 [PATCH 0/3] gdb/arm: Cortex-M33 trustzone stack unwinding fixes Yvan Roux
2022-05-16 13:58 ` [PATCH 1/3] gdb/arm: Set the correct address to the FPU register on Yvan Roux
2022-05-16 14:46 ` Christophe Lyon
2022-05-17 9:49 ` Torbjorn SVENSSON
2022-05-17 15:44 ` Luis Machado
2022-05-18 19:24 ` Torbjorn SVENSSON
2022-05-19 8:17 ` Luis Machado
2022-05-19 13:24 ` Torbjorn SVENSSON
2022-06-02 9:20 ` Yvan Roux
2022-05-16 13:59 ` [PATCH 2/3] gdb/arm: Fetch initial sp value prior to compare Yvan Roux
2022-05-16 14:56 ` Christophe Lyon
2022-05-17 9:54 ` Torbjorn SVENSSON
2022-05-16 14:00 ` [PATCH 3/3] gdb/arm: Track msp and psp Yvan Roux
2022-05-16 14:25 ` Lancelot SIX
2022-05-17 15:52 ` Luis Machado
2022-05-18 19:18 ` Torbjorn SVENSSON
2022-05-19 8:07 ` Luis Machado [this message]
2022-05-19 13:16 ` Torbjorn SVENSSON
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=495624cf-b21d-45ca-d6f6-090276e89e9c@arm.com \
--to=luis.machado@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=torbjorn.svensson@st.com \
--cc=yvan.roux@foss.st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).