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 57E3A3858015; Fri,  5 Nov 2021 15:51:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 57E3A3858015
From: "tarek.bouchkati at gmail dot com" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug gdb/28549] ARM/Cortex-M: improper stack unwinding when the
 target is in lockup state
Date: Fri, 05 Nov 2021 15:51:51 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gdb
X-Bugzilla-Component: gdb
X-Bugzilla-Version: 9.2
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tarek.bouchkati at gmail dot com
X-Bugzilla-Status: WAITING
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: luis.machado at linaro dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-28549-4717-4XTi38TdFT@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-28549-4717@http.sourceware.org/bugzilla/>
References: <bug-28549-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
X-BeenThere: gdb-prs@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gdb-prs mailing list <gdb-prs.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-prs>,
 <mailto:gdb-prs-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/gdb-prs/>
List-Help: <mailto:gdb-prs-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-prs>,
 <mailto:gdb-prs-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Nov 2021 15:51:51 -0000

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

--- Comment #5 from Tarek BOCHKATI <tarek.bouchkati at gmail dot com> ---
0xfffffffe is just one missing magic address.
according to arm:=20
> During LOCKUP, the PC will be forced to 0xFFFFFFFx

so all 0xFFFFFFFx should be considered magic as well, and this hides several
EXC_RETURN

I'm wondering why we are linking this to EXC_RETURN, since this function is
used to check PC values and EXC_RETURN values are loaded into LR.

more literature:
according to ARM v6M Arch ref man (ARM DDI 0419E page B1-198),
section B1.5.8: Exception return behavior:
> An exception return occurs when the processor is in Handler mode
> and one of the following instructions loads a value of 0xFXXXXXXX into th=
e PC

according to this all 0xfxxxxxxx values are magic
the same text is present in ARM v7M arch ref man

in ARM v8M ref man, section B3.22:
> ... loads an EXC_RETURN value, 0xFFXXXXXX, into the PC


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

regarding:=20
is it right to display something like <signal handler called>?
it's fine for me, unless there is a way to display something similar to
"exception"=20

but I agree, if we want to have a minor fix/change:
we can limit to adding the 3 magic addresses:
+      case 0xeffffffe:
+      case 0xfffffffe:
+      case 0xffffffff:

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