From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22425 invoked by alias); 20 Apr 2012 13:15:34 -0000 Received: (qmail 22375 invoked by uid 22791); 20 Apr 2012 13:15:33 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,MSGID_MULTIPLE_AT,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Apr 2012 13:14:58 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Fri, 20 Apr 2012 14:14:55 +0100 Received: from shawin053 ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Apr 2012 14:16:06 +0100 From: "Terry Guo" To: "'Pedro Alves'" , "Jonathan Larmour" Cc: , "Ilija Kocho" References: <4F902B4E.9070704@eCosCentric.com> <4F91593B.4020309@redhat.com> In-Reply-To: <4F91593B.4020309@redhat.com> Subject: RE: [patch] Add support for VFP d16 layout for Cortex-M4 Date: Fri, 20 Apr 2012 13:20:00 -0000 Message-ID: <001501cd1ef7$bd79e490$386dadb0$@guo@arm.com> MIME-Version: 1.0 X-MC-Unique: 112042014145509501 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00676.txt.bz2 Hi Pedro, > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Friday, April 20, 2012 8:40 PM > To: Jonathan Larmour > Cc: gdb-patches@sourceware.org; Ilija Kocho; Terry Guo; Pedro Alves > Subject: Re: [patch] Add support for VFP d16 layout for Cortex-M4 >=20 > On 04/19/2012 04:12 PM, Jonathan Larmour wrote: >=20 > > As mentioned in my response to the GDB list mail > > , I have a patch > to > > allow easy automatic use of Cortex-M targets with a register layout > with > > 16 double precision / 32 single precision regs. This is as used in > the > > increasingly popular Cortex-M4 core. > > > > I have chosen to use the remote packet guessing approach again, > rather > > than inferring from the executable's ELF header, because not everyone > will > > actually want to use hardware FP just because they're using that core, > so > > what the stub actually supports is a better indicator of what is > wanted. >=20 >=20 > I'd like to make it clear that the guesses mechanism is a just a > fallback > mechanism, useful when its too late to change the stubs out there to > send the xml description to gdb themselves. It's not the ideal way > forward, > and it can't scale beyond a few guesses. The right thing is for > the stubs themselves to report the xml descriptions to GDB (with > qXfer:features:read), > not to have them depend on GDB being able to guess it. >=20 Ideally using the qXfer:features:read is the most natural way. Can you confirm that once it is used, the guess mechanism won't be resorted for M4? The code in trunk already has two guess methods for Cortex-M. I don't want things get messed up. Another thing in my mind is as Jonathan said before, the stub that will be programmed into flash is sensitive to the bytes. So I guess they may tend to save bytes by not returning target.xml. I am not sure what I am assuming is true. Please correct me if I am wrong. BR, Terry