This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: eCos GNU tools 4.6.2-20120125 ready for testing


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.

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]