[RFC] Support ARMv7M FPU registers in GDB

[RFC] Support ARMv7M FPU registers in GDB

[Terry Guo]

Hi,

The ARM Cortex-M4 processor is based on ARMv7M architecture and enhanced by
its DSP extension and Floating Point Unit. As more and more M4 based boards
are emerging in the market, I would like to propose following solution for
GDB to support the access of FPU registers.

1). I studied how the GDB support other Cortex-M core like Cortex-M3 and
noticed that the GDB has to use "g_packet_guess" mechanism to maintain
compatibility. I don't know why some gdb stubs return faked FPA registers
and some don't. But as M4 board are all recently released board, so maybe it
is time for M4 gdb stub to return a correct g packet: 16 core registers +
xpsr register + 16 double precision FPU registers + fpscr register. Does
this expectation make sense? Is it possible for gdb stub to do so?

2). The GDB is going to need a new target description file to describe M4
register layout. I propose arm-with-m-fpu.xml for its filename. For file
content, it just includes another two existing xml files arm-m-profile.xml
and arm-vfpv2.xml.

3). In function arm_gdbarch_init, I propose to add more checks where we
check whether the target is cortex-m. At this point, once the gdb figures
out the target is cortex-m4 from the ELF attributes, we then set the tdesc
to tdesc_arm_with_m_fpu.

4). No need to describe the single precision FPU registers in XML file
because the GDB will handle them as aliases of double precision format.

5). According to M4 Debug architecture, there is a pretty straight way for
stub to access FPU registers in single precision format. But there is no
direct way to access FPU registers in double precision format. So one more
thing for GDB stub is that the stub needs to do more work to construct
double precision register from two single precision registers.

Is this proposal good enough? Please feel free to comment. And any of them
are welcomed.

BR,
Terry

Re: [RFC] Support ARMv7M FPU registers in GDB

[Jonathan Larmour]

Hi Terry,

On 19/04/12 04:48, Terry Guo wrote:
> 
> The ARM Cortex-M4 processor is based on ARMv7M architecture and enhanced by
> its DSP extension and Floating Point Unit. As more and more M4 based boards
> are emerging in the market, I would like to propose following solution for
> GDB to support the access of FPU registers.
> 
> 1). I studied how the GDB support other Cortex-M core like Cortex-M3 and
> noticed that the GDB has to use "g_packet_guess" mechanism to maintain
> compatibility. I don't know why some gdb stubs return faked FPA registers
> and some don't.

Because of the history of the initial Cortex-M development being just a
variant of ARM. The XPSR was treated as a tweaked CPSR and so on. So in
the first instance the register format used by stubs didn't change from
the ARM default. The target description support was also quite new at that
point.

> But as M4 board are all recently released board, so maybe it
> is time for M4 gdb stub to return a correct g packet: 16 core registers +
> xpsr register + 16 double precision FPU registers + fpscr register. Does
> this expectation make sense? Is it possible for gdb stub to do so?

Yes, and I have already been developing a patch to do exactly this - I had
been waiting for confirmation from someone I was working with that it
worked fine, and as it happens I've just had that.

> 2). The GDB is going to need a new target description file to describe M4
> register layout. I propose arm-with-m-fpu.xml for its filename. For file
> content, it just includes another two existing xml files arm-m-profile.xml
> and arm-vfpv2.xml.

Maybe since you're in ARM you have a better idea of the future product
roadmap (and we're talking _years_ into the future here), but I have named
it arm-with-m-vfp-d16, because Cortex-M4 uses the VFPv4 single precision
16d regs layout (corresponding to -mfpu=fpv4-sp-d16 in GCC). That is
different from VFP units with other cores. I could conceive of future
Cortex-M's coming out with a wider variety of FPU layouts than just that,
such as the full VFPv4.

> 3). In function arm_gdbarch_init, I propose to add more checks where we
> check whether the target is cortex-m. At this point, once the gdb figures
> out the target is cortex-m4 from the ELF attributes, we then set the tdesc
> to tdesc_arm_with_m_fpu.

Although you need to be aware that just because someone built the program
with -mcpu=cortex-m4, it doesn't mean they wanted to use hardware floating
point. Hardware FPU use can have hardware context switch consequences that
some people would be sensitive to.

For that reason, my patch actually only added a new 'g' packet guess based
on the size of the stub's response:

+      /* M-profile plus M4F VFP.  */
+      register_remote_g_packet_guess (gdbarch,
+				      /* r0-r12,sp,lr,pc; d0-d15; fpscr,xpsr */
+				      (16 * INT_REGISTER_SIZE)
+				      + (16 * VFP_REGISTER_SIZE)
+				      + (2 * INT_REGISTER_SIZE),
+				      tdesc_arm_with_m_vfp_d16);

> 4). No need to describe the single precision FPU registers in XML file
> because the GDB will handle them as aliases of double precision format.

Correct.

> 5). According to M4 Debug architecture, there is a pretty straight way for
> stub to access FPU registers in single precision format. But there is no
> direct way to access FPU registers in double precision format. So one more
> thing for GDB stub is that the stub needs to do more work to construct
> double precision register from two single precision registers.

Since that is just concatenation, I'm not sure I see any real issue?

> Is this proposal good enough? Please feel free to comment. And any of them
> are welcomed.

I will submit my patch for discussion to the gdb-patches list in a moment.
Perhaps you might like to have a look when it's there and see what you think.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
  **   Visit us at NEW:UK - the UK Embedded & Electronics Exhibition  **
  **   ARM Partner Pavilion/Stand #114. 18-19 April. Birmingham NEC   **
------["Si fractum non sit, noli id reficere"]------       Opinions==mine