This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] (ARM Cortex-M) FPU and PSP aware exception frame unwinder
- From: James-Adam Renquinha Henri <arenquinha at cimeq dot qc dot ca>
- To: Tristan Gingold <gingold at adacore dot com>, Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Christopher Friedt <chrisfriedt at gmail dot com>
- Date: Wed, 20 Apr 2016 19:14:23 -0400
- Subject: Re: [PATCH] (ARM Cortex-M) FPU and PSP aware exception frame unwinder
- Authentication-results: sourceware.org; auth=none
- References: <5706DA27 dot 1070308 at cimeq dot qc dot ca> <570C1D85 dot 1060706 at redhat dot com> <C52395DC-8725-47F6-96DE-4DA0A9FDFD4F at adacore dot com>
Le 2016-04-14 02:34, Tristan Gingold a écrit :
Hmmmm, er, I'm pretty sure you're referring to the
`user_reg_map_name_to_regnum` calls, but I'm not sure what the info in
the link is supposed to tell me. This is the first time I play into the
guts of `gdb` and am confronted by its inner complexity, though. I
wasn't aware of "target features", haha :P
On 11 Apr 2016, at 23:56, Pedro Alves <firstname.lastname@example.org> wrote:
[Adding a few folks who either worked on or expressed
interest in this before.]
On 04/07/2016 11:07 PM, James-Adam Renquinha Henri wrote:
I submitted it as a bug to the GNU ARM Embedded initially, see here for
Basically, this patch allow gdb to unwind properly an extended stack
frame, that is an exception frame with FPU state stacked. Additionally,
because all Cortex-M variants have 2 stack pointers, the Main Stack
Pointer (MSP) and the Process Stack Pointer (PSP), the code in the patch
also check which stack was used prior to the exception. That way,
backtraces work beautifully.
In my original submission, I mentioned a known issue that I didn't try
to fix *yet*, because that would involve a lot more work, and the impact
is relatively minor: for a given outer frame, some FPU registers may not
be reported correctly. I hope you don't mind too much. I consider the
current patch still useful, because at least backtraces work, and it's
an annoyance not to be able to get them.
Thanks for the patch. However, we should really add new target
descriptions/features that describe these registers to gdb
instead of looking them up by name. Please see:
This is what I understand, please correct me if I'm wrong:
- When using OpenOCD, gdb gets a target description while communicating
with the server, so it knows the other registers like "psp", "control",
"fpscr" and other system registers exist. When using Qemu, gdb uses the
"org.gnu.gdb.arm.m-profile" feature from binutils-gdb and the system
registers are lacking from the XML file. This is the problem Christopher
Friedt had in the thread;
- If the system registers were in "org.gnu.gdb.arm.m-profile", then we
could rely on their presence and put them in the `gdb_regnum` enum in
arch/arm.h and assign them fixed offsets, removing the need to get them
- By finding registers by name, we're dependent of the supplied target
description and even getting PSP (which is always available on any
Cortex-M core BTW) can fail, and the code I provided will crash.
(I realized LR is accessible via `ARM_LR_REGNUM`. Ooops)
I'm not sure to follow, but it seems the inclusion of the system
registers into "org.gnu.gdb.arm.m-profile" is still an open question. My
opinion is to include them, because all Cortex-M have them. This can be
seen in B1.4 of the ARMv6-M Reference Manual:
The ARMv6-M profile has the following registers closely coupled to
- General purpose registers R0-R12.
- Two Stack Pointer registers, SP_main and SP_process. These are
banked versions of SP, also described as R13.
- The Link Register, LR also described as R14.
- The Program Counter, PC, sometimes described as R15.
- Status registers for flags, execution state bits, and the current
- A mask register, PRIMASK, used to manage the prioritization
scheme for exceptions and interrupts.
- A control register, CONTROL that identifies the current stack.
(later, they define SP_main as synonymous to MSP, and likewise for
SP_process with PSP)
Cortex-M0 and Cortex-M0+ are based on the ARMv6-M profile, and that
profile is upward compatible with the ARMv7-M profile which is used in
the Cortex-M3 and Cortex-M4(F): code compiled for Cortex-M0 can run on
any Cortex-M. Meaning, ARMv6-M is the lowest common denominator of all
Cortex-M. If the ARMv6-M architecture has these system registers, then
all Cortex-M have them.
And see more in this earlier attempt at getting the unwinder working:
Tristan also wrote yet another patch for the same, as mentioned at:
Tristan, did you ever manage to post that?
Not yet. But I have tested it with two different probes.
Lots of duplicated effort. :-/ :-(
Indeed. But we know that the common part is correct!
Well, technically the efforts are not entirely duplicated, for the scope
of my patch is a bit broader, it deals with the FPU (found on
Cortex-M4F), too. :)
James-Adam Renquinha Henri, Ing. jr