Re: eCos GNU tools 4.6.2-20120125 ready for testing

[Tomas Frydrych <tf+lists.ecos@r-finger.com>]

On 05/03/12 10:16, Ilija Kocho wrote:
> 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

I think the original inclusion of the FP registers is to accommodate
earlier version of GDB that expected any arm platform to have FP
registers even though few really did -- I think it will be necessary for
the gdb stubs to have a CDL option to choose which gdb incarnation to
target, I don't think there is any way to do the right thing automatically.

I do not know if gdb 7.3 expects any sort of fp registers on M4, if so
it might be necessary for the definitions in cortexm_stubs.h to be more
finely honed based on the cortex-m variant.

Tomas