From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 82F4C38CC7B2; Fri, 21 Oct 2022 20:59:17 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 82F4C38CC7B2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org;
	s=default; t=1666385957;
	bh=FyreqkoZg+9U/uNYYRrBU1SZ1F1RSYgVZxRb9d7392g=;
	h=From:To:Subject:Date:From;
	b=ZIk4kUhiJH+3NLhlDoAxYQOZZRk5f4NVS93WchLvBZSESVdMmlPt12T+hCFNl1Za2
	 bNO8jZRkOzDH9qNxMwv3SIO7V6TOLSsX2ENnka0FVmYIcbfk32zlIqvxz4mI0+sVGh
	 NLs1jLOWafyNf8a7i7xSlX6Djgs98qeg5O9lVPd0=
From: "tomas.vanek at fbl dot cz" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug tdep/29716] New: Arm v8 M-profile FNC_RETURN unwinder uses
 wrong stack
Date: Fri, 21 Oct 2022 20:59:16 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: tdep
X-Bugzilla-Version: HEAD
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: minor
X-Bugzilla-Who: tomas.vanek at fbl dot cz
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-29716-4717@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gdb-prs.sourceware.org>

https://sourceware.org/bugzilla/show_bug.cgi?id=3D29716

            Bug ID: 29716
           Summary: Arm v8 M-profile FNC_RETURN unwinder uses wrong stack
           Product: gdb
           Version: HEAD
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: tdep
          Assignee: unassigned at sourceware dot org
          Reporter: tomas.vanek at fbl dot cz
  Target Milestone: ---

Discovered on STM32L552 with Cortex-M33, should be same for all ARMv8-M dev=
ices
with the security extension.

A secure code runs in thread mode and uses MSP_S because CONTROL_S bit SPSE=
L =3D
0
A non-secure function is called from secure code.
Command 'backtrace' does not show the correct stack frames:

 (gdb) bt
 #0  NonSecureFc ()
 #1  <signal handler called>
 #2  0x00000000 in ?? ()
 Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The problem is in arm-tdep.c:3394, function arm_m_exception_cache (),
block if (fnc_return):

  ULONGEST xpsr =3D get_frame_register_unsigned (this_frame, ARM_PS_REGNUM);
  if ((xpsr & 0xff) !=3D 0)
    /* Handler mode: This is the mode that exceptions are handled in.  */
    arm_cache_switch_prev_sp (cache, tdep, tdep->m_profile_msp_s_regnum);
  else
    /* Thread mode: This is the normal mode that programs run in.  */
    arm_cache_switch_prev_sp (cache, tdep, tdep->m_profile_psp_s_regnum);

This code does not comply
Arm=C2=AEv8-M Architecture Reference Manual
B3.8 Stack pointer
IDMLS "In Thread mode, CONTROL.SPSEL determines whether the PE uses the mai=
n or
process stack"

and uses process stack regardless of SPSEL.

The test should check SPSEL bit of CONTROL_S register.
Unfortunately the current arm-tdep is not aware of this register, we need to
look up the register number in arm_gdbarch_init().

Moreover stack unwinders probably do not keep track of CONTROL_S updates.
Even if we neglect usually very seldom updates of SPSEL and use the value f=
rom
the innermost frame we have better chance to see correct stack frames.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=