From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28207 invoked by alias); 20 Apr 2012 12:41:00 -0000 Received: (qmail 28108 invoked by uid 22791); 20 Apr 2012 12:40:58 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Apr 2012 12:40:40 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3KCeUtr024542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Apr 2012 08:40:30 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3KCeRJ2032401; Fri, 20 Apr 2012 08:40:28 -0400 Message-ID: <4F91593B.4020309@redhat.com> Date: Fri, 20 Apr 2012 12:43:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 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 References: <4F902B4E.9070704@eCosCentric.com> In-Reply-To: <4F902B4E.9070704@eCosCentric.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00673.txt.bz2 On 04/19/2012 04:12 PM, Jonathan Larmour wrote: > 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. 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. Cortex-M4 stubs can already send a xml description equivalent to this new description to gdb today (without this patch), and things will work equally well, since the xml description can be (as yours is) simply built using the org.gnu.gdb.arm.m-profile and org.gnu.gdb.arm.vfp standard description features. Is it too late change the stubs that triggered this need to have them send a xml description? Despite this patch going in, that's the right right to do. That said, I'm no ARM expert, but I don't see anything wrong with the patch. And having the xml file in the tree that stubs can copy freely is always good. > +/* Say how long VFP double precision registers are. Used for documentation ^ Double space after full stop, please. > + purposes and code readability. These are fixed at 64 bits. */ ^ Ditto. -- Pedro Alves