This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] (ARM Cortex-M) FPU and PSP aware exception frame unwinder

Le 2016-04-14 02:34, Tristan Gingold a écrit :

On 11 Apr 2016, at 23:56, Pedro Alves <> 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:

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

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 name; - 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 the processor:
    - 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 exception number. - 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
Ingénieur d'application

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]