From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1089 invoked by alias); 5 Mar 2012 12:56:54 -0000 Received: (qmail 1080 invoked by uid 22791); 5 Mar 2012 12:56:53 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,SARE_LWSHORTT,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from r-finger.com (HELO r-finger.com) (178.79.160.5) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Mar 2012 12:56:40 +0000 Received: from [192.168.0.2] (host86-133-40-127.range86-133.btcentralplus.com [86.133.40.127]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by r-finger.com (Postfix) with ESMTPSA id 980A360E52 for ; Mon, 5 Mar 2012 12:56:39 +0000 (GMT) Message-ID: <4F54B801.9060104@r-finger.com> Date: Mon, 05 Mar 2012 12:56:00 -0000 From: Tomas Frydrych User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120216 Icedove/8.0 MIME-Version: 1.0 To: ecos-devel@ecos.sourceware.org Subject: Re: eCos GNU tools 4.6.2-20120125 ready for testing References: <4F106345.4080902@siva.com.mk> <4F11574D.9070002@dallaway.org.uk> <4F11AC54.7000902@siva.com.mk> <4F1CB41C.90900@jifvik.org> <4F1DA9A0.5070702@siva.com.mk> <4F1FF5AD.4010901@ecoscentric.com> <4F39887A.5050905@siva.com.mk> <4F50F700.5080902@ecoscentric.com> <4F521D6A.4010500@siva.com.mk> <4F52B2C8.4010809@schuilenburg.org> <4F53C46B.4090502@dallaway.org.uk> <4F54798C.2070700@r-finger.com> <4F547FBE.8080507@r-finger.com> <4F548C37.2090306@dallaway.org.uk> <4F549276.7050600@siva.com.mk> In-Reply-To: <4F549276.7050600@siva.com.mk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2012-03/txt/msg00014.txt.bz2 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