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

[James-Adam Renquinha Henri <arenquinha@cimeq.qc.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.