public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Yvan Roux <yvan.roux@foss.st.com>
To: <gdb-patches@sourceware.org>
Cc: Christophe Lyon <christophe.lyon@arm.com>,
	Torbjorn SVENSSON <torbjorn.svensson@st.com>,
	Luis Machado <Luis.Machado@arm.com>
Subject: Re: [PATCH] gdb/arm: Document and fix exception stack offsets
Date: Thu, 2 Jun 2022 16:29:48 +0200	[thread overview]
Message-ID: <20220602142948.GC23363@gnbcxd0114.gnb.st.com> (raw)
In-Reply-To: <f8d4ba87-ca16-afbe-253a-b51e85c9d19b@arm.com>

On Thu, Jun 02, 2022 at 12:09:47PM +0200, Christophe Lyon wrote:
> 
> 
> On 6/2/22 11:23, Yvan Roux via Gdb-patches wrote:
> > Hi,
> > 
> > Add a description of exception entry context stacking and fix next
> > frame offset (at 0xA8 relative to R0 location) as well as FPU
> > registers ones (starting at 0x68 relative to R0).
> 
> Thanks, adding the picture will really help maintenance!
> So IIUC, the existing code is broken when there is no Secure->Non-Secure
> transition additional context saved?

Thanks, yes that's it, the current offsets assume that the additional contexts
are present.

> 
> > 
> > Signed-off-by: Torbj�rn SVENSSON <torbjorn.svensson@st.com>
> > Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
> > ---
> >   gdb/arm-tdep.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++----
> >   1 file changed, 58 insertions(+), 4 deletions(-)
> > 
> > diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
> > index 50ec41a66b1..759dfd76ef6 100644
> > --- a/gdb/arm-tdep.c
> > +++ b/gdb/arm-tdep.c
> > @@ -3417,6 +3417,57 @@ arm_m_exception_cache (struct frame_info *this_frame)
> >     /* Fetch the SP to use for this frame.  */
> >     unwound_sp = arm_cache_get_prev_sp_value (cache, tdep);
> > +  /* Exception entry context stacking as described into ARMv8-M (section B3.19)
> > +     and ARMv7-M (sections B1.5.6 and B1.5.7) Architecture Reference Manuals.
> > +
> > +                           SP Offsets
> > +              Without                         With
> > +            Callee Regs                    Callee Regs
> 
> Could make the description here (Without Callee Regs) a more obvious match
> of the one below (Additional State Ctx When transitioning from Secure to
> Non-secure)?

OK
 
> > +
> > +                      +-------------------+
> > +               0xA8   |                   |   0xD0
> > +                      +===================+         --+  <-- Original SP
> > +               0xA4   |        S31        |   0xCC    |
> > +                      +-------------------+           |
> > +                               ...                    |  Additional FP Ctx
> Here and elsewhere, I suggest Ctx -> Context

OK

> > +                      +-------------------+           |
> > +               0x68   |        S16        |   0x90    |
> > +                      +===================+         --+
> > +               0x64   |      Reserved     |   0x8C    |
> > +                      +-------------------+           |
> > +               0x60   |       FPSCR       |   0x88    |
> > +                      +-------------------+           |
> > +               0x5C   |        S15        |   0x84    |  FP Ctx
> > +                      +-------------------+           |
> > +                               ...                    |
> > +                      +-------------------+           |
> > +               0x20   |         S0        |   0x48    |
> > +                      +===================+         --+
> > +               0x1C   |       xPSR        |   0x44    |
> > +                      +-------------------+           |
> > +               0x18   |  Return address   |   0x40    |
> > +                      +-------------------+           |
> > +               0x14   |      LR(R14)      |   0x3C    |
> > +                      +-------------------+           |
> > +               0x10   |        R12        |   0x38    |  State Ctx
> > +                      +-------------------+           |
> > +               0x0C   |         R3        |   0x34    |
> > +                      +-------------------+           |
> > +                               ...                    |
> > +                      +-------------------+           |
> > +               0x00   |         R0        |   0x28    |
> > +                      +===================+         --+
> > +                      |        R11        |   0x24    |
> > +                      +-------------------+           |
> > +                               ...                    |
> > +                      +-------------------+           |  Additional State Ctx
> > +                      |         R4        |   0x08    |  When transitioning from
> > +                      +-------------------+           |  Secure to Non-secure
> > +                      |      Reserved     |   0x04    |
> > +                      +-------------------+           |
> > +                      |  Magic signature  |   0x00    |
> > +                      +===================+         --+  <-- New SP  */
> > +
> >     /* With the Security extension, the hardware saves R4..R11 too.  */
> >     if (exc_return && tdep->have_sec_ext && secure_stack_used
> >         && (!default_callee_register_stacking || exception_domain_is_secure))
> > @@ -3475,25 +3526,28 @@ arm_m_exception_cache (struct frame_info *this_frame)
> >         if (tdep->have_sec_ext && !default_callee_register_stacking)
> >   	{
> >   	  /* Handle floating-point callee saved registers.  */
> > -	  fpu_regs_stack_offset = 0x90;
> > +	  fpu_regs_stack_offset = unwound_sp + sp_r0_offset + 0x68;
> >   	  for (i = 8; i < 16; i++)
> >   	    {
> >   	      cache->saved_regs[ARM_D0_REGNUM + i].set_addr (fpu_regs_stack_offset);
> >   	      fpu_regs_stack_offset += 8;
> >   	    }
> > -	  arm_cache_set_active_sp_value (cache, tdep, unwound_sp + sp_r0_offset + 0xD0);
> > +	  arm_cache_set_active_sp_value (cache, tdep,
> > +					 unwound_sp + sp_r0_offset + 0xA8);
> >   	}
> >         else
> >   	{
> >   	  /* Offset 0x64 is reserved.  */
> > -	  arm_cache_set_active_sp_value (cache, tdep, unwound_sp + sp_r0_offset + 0x68);
> > +	  arm_cache_set_active_sp_value (cache, tdep,
> > +					 unwound_sp + sp_r0_offset + 0x68);
> >   	}
> >       }
> >     else
> >       {
> >         /* Standard stack frame type used.  */
> > -      arm_cache_set_active_sp_value (cache, tdep, unwound_sp + sp_r0_offset + 0x20);
> > +      arm_cache_set_active_sp_value (cache, tdep,
> > +				     unwound_sp + sp_r0_offset + 0x20);
> >       }
> >     /* If bit 9 of the saved xPSR is set, then there is a four-byte
> 
> 
> Thanks,
> 
> Christophe

Here is the updated version:

---
 gdb/arm-tdep.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 61 insertions(+), 4 deletions(-)

diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
index 50ec41a66b1..6998fbd24e9 100644
--- a/gdb/arm-tdep.c
+++ b/gdb/arm-tdep.c
@@ -3417,6 +3417,60 @@ arm_m_exception_cache (struct frame_info *this_frame)
   /* Fetch the SP to use for this frame.  */
   unwound_sp = arm_cache_get_prev_sp_value (cache, tdep);
 
+  /* Exception entry context stacking are described in ARMv8-M (section B3.19)
+     and ARMv7-M (sections B1.5.6 and B1.5.7) Architecture Reference Manuals.
+
+     The following figure shows the structure of the stack frame when Security
+     and Floating-point extensions are present.
+
+                          SP Offsets
+            Without                         With
+          Callee Regs                    Callee Regs
+                                    (Secure -> Non-Secure)
+                    +-------------------+
+             0xA8   |                   |   0xD0
+                    +===================+         --+  <-- Original SP
+             0xA4   |        S31        |   0xCC    |
+                    +-------------------+           |
+                             ...                    |  Additional FP Context
+                    +-------------------+           |
+             0x68   |        S16        |   0x90    |
+                    +===================+         --+
+             0x64   |      Reserved     |   0x8C    |
+                    +-------------------+           |
+             0x60   |       FPSCR       |   0x88    |
+                    +-------------------+           |
+             0x5C   |        S15        |   0x84    |  FP Context
+                    +-------------------+           |
+                             ...                    |
+                    +-------------------+           |
+             0x20   |         S0        |   0x48    |
+                    +===================+         --+
+             0x1C   |       xPSR        |   0x44    |
+                    +-------------------+           |
+             0x18   |  Return address   |   0x40    |
+                    +-------------------+           |
+             0x14   |      LR(R14)      |   0x3C    |
+                    +-------------------+           |
+             0x10   |        R12        |   0x38    |  State Context
+                    +-------------------+           |
+             0x0C   |         R3        |   0x34    |
+                    +-------------------+           |
+                             ...                    |
+                    +-------------------+           |
+             0x00   |         R0        |   0x28    |
+                    +===================+         --+
+                    |        R11        |   0x24    |
+                    +-------------------+           |
+                             ...                    |
+                    +-------------------+           |  Additional State Context
+                    |         R4        |   0x08    |  When transitioning from
+                    +-------------------+           |  Secure to Non-secure
+                    |      Reserved     |   0x04    |
+                    +-------------------+           |
+                    |  Magic signature  |   0x00    |
+                    +===================+         --+  <-- New SP  */
+
   /* With the Security extension, the hardware saves R4..R11 too.  */
   if (exc_return && tdep->have_sec_ext && secure_stack_used
       && (!default_callee_register_stacking || exception_domain_is_secure))
@@ -3475,25 +3529,28 @@ arm_m_exception_cache (struct frame_info *this_frame)
       if (tdep->have_sec_ext && !default_callee_register_stacking)
 	{
 	  /* Handle floating-point callee saved registers.  */
-	  fpu_regs_stack_offset = 0x90;
+	  fpu_regs_stack_offset = unwound_sp + sp_r0_offset + 0x68;
 	  for (i = 8; i < 16; i++)
 	    {
 	      cache->saved_regs[ARM_D0_REGNUM + i].set_addr (fpu_regs_stack_offset);
 	      fpu_regs_stack_offset += 8;
 	    }
 
-	  arm_cache_set_active_sp_value (cache, tdep, unwound_sp + sp_r0_offset + 0xD0);
+	  arm_cache_set_active_sp_value (cache, tdep,
+					 unwound_sp + sp_r0_offset + 0xA8);
 	}
       else
 	{
 	  /* Offset 0x64 is reserved.  */
-	  arm_cache_set_active_sp_value (cache, tdep, unwound_sp + sp_r0_offset + 0x68);
+	  arm_cache_set_active_sp_value (cache, tdep,
+					 unwound_sp + sp_r0_offset + 0x68);
 	}
     }
   else
     {
       /* Standard stack frame type used.  */
-      arm_cache_set_active_sp_value (cache, tdep, unwound_sp + sp_r0_offset + 0x20);
+      arm_cache_set_active_sp_value (cache, tdep,
+				     unwound_sp + sp_r0_offset + 0x20);
     }
 
   /* If bit 9 of the saved xPSR is set, then there is a four-byte
-- 
2.17.1


  reply	other threads:[~2022-06-02 14:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-02  9:23 Yvan Roux
2022-06-02 10:09 ` Christophe Lyon
2022-06-02 14:29   ` Yvan Roux [this message]
2022-06-08 13:31     ` Luis Machado
2022-06-08 13:59       ` Luis Machado
2022-06-08 14:33         ` Yvan Roux

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=20220602142948.GC23363@gnbcxd0114.gnb.st.com \
    --to=yvan.roux@foss.st.com \
    --cc=Luis.Machado@arm.com \
    --cc=christophe.lyon@arm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=torbjorn.svensson@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).