On 05.03.2012 10:49, John Dallaway wrote: > Hi Tomas > > Tomas Frydrych wrote: > >> On 05/03/12 08:30, Tomas Frydrych wrote: >>> On 04/03/12 19:37, John Dallaway wrote: >>>> However, this success was achieved using arm-eabi-gdb 6.8.50.20080706. >>>> There does appear to be an issue with the length of the 'g' packet when >>>> using the new arm-eabi-gdb 7.3.1: >>>> >>>>> (gdb) tar rem /dev/ttyS0 >>>>> Remote debugging using /dev/ttyS0 >>>>> Remote 'g' packet reply is too long: >>>>> e14e000810000000000000001000000000000000000000000000000000000000000000000000000000000000fccf0d6800000000e8cf0d6895680008e24e00080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021 >>>>> (gdb) >>>> We will need to look into why the packet length has apparently changed >>>> for Cortex-M targets. I can connect to an ARM7 target using the new GDB >>>> without problem. >>> This is a mismatch between the number of registers a gdb server reports >>> and the number that gdb expects for the given architecture. In this case >>> too many registers are being reported. IIRC, there should be 8 hex >>> digits for a register, so the above string seems to represent 42 >>> registers instead of the 21 that Cortex-M has. Looks like a bug in the >>> monitor stub code, or perhaps a work around for something broken in >>> older toolchains? >> Done bit further digging around the sources, >> hal/cortexm/arch/.../cortexm_stub.h:64 defines 16 gpr, 8 fp or 12 bytes >> each and 2 ps registers; this adds up to the 336 bytes of the above output. > Yes. It looks like the FPA registers have been dropped from the default > register set for Cortex-M targets in recent GDB. In the longer term, we > should add a CDL option to our GDB stub code to accommodate this change. > In the short term, I will look at creating a GDB target description file > that we can use to accommodate the larger register set returned by our > stubs.
Could the reason for this be because Cortex-M(4) uses VFP architecture rather than FPA? The FPU used on Cortex-M4 is FPv4-SP-d16 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439c/BEHFGGGE.html Ilija
