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

[James-Adam Renquinha Henri <arenquinha at cimeq dot qc dot ca>]

Le 2016-04-14 02:34, Tristan Gingold a écrit :
> > On 11 Apr 2016, at 23:56, Pedro Alves <palves@redhat.com> wrote:
> >
> > Hi,
> >
> > [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
> > > details: https://bugs.launchpad.net/gcc-arm-embedded/+bug/1566054
> > >
> > > 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:
> >
> > https://sourceware.org/ml/gdb-patches/2015-12/msg00273.html
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:
> >
> > https://sourceware.org/ml/gdb-patches/2014-09/msg00649.html
> >
> > Tristan also wrote yet another patch for the same, as mentioned at:
> >
> >   https://sourceware.org/ml/gdb-patches/2015-12/msg00281.html
> >
> > 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!
>
> Tristan.

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
CIMEQ INC.