From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3209 invoked by alias); 19 Apr 2012 16:59:36 -0000 Received: (qmail 3196 invoked by uid 22791); 19 Apr 2012 16:59:34 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Apr 2012 16:59:01 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 99E802F78005; Thu, 19 Apr 2012 17:58:59 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+cvxsmM0kx5; Thu, 19 Apr 2012 17:58:54 +0100 (BST) Message-ID: <4F90444C.5030505@eCosCentric.com> Date: Thu, 19 Apr 2012 17:30:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: Terry Guo CC: gdb-patches@sourceware.org, Ilija Kocho , Terry Guo Subject: Re: [patch] Add support for VFP d16 layout for Cortex-M4 References: <4F902B4E.9070704@eCosCentric.com> <4F9035F4.7060101@eCosCentric.com> In-Reply-To: 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/msg00639.txt.bz2 On 19/04/12 17:18, Terry Guo wrote: > On Thu, Apr 19, 2012 at 11:57 PM, Jonathan Larmour wrote: >> >> STM32F4 is likely to follow very soon after. Ironically, it's not likely >> to be committed until we have some confidence that what goes into GDB will >> match up with what the stub is doing! We wouldn't want to commit something >> that has to change in an incompatible way. > > Agree. I am also worrying about the gdb stub. If they return something > different from what we currently expect, we will have to make another > change. I think there's probably very little variation in what would make sense. Ultimately the layout used on the wire reflects the realities of the real register set: the standard Cortex-M regs plus the VFP ones. Theoretically it's possible someone might like to do away with the VFP pseudo regs and make the format be 32 single precision registers; but if you did, it would need a fair bit more GDB work for no actual practical benefit. So I expect the format I've proposed is the natural format everyone would want to use. > So I am talking to OpenOCD to share with them what the gdb is > going to do. There are many other gdb stub vendors like JLink. I plan > to talk with them and hope to achieve some consensus between GDB and > stub. Because they run on the host, something that's easier for them to do is supply their own target description XML over the wire. It's also easier to just update and run a new version if they need to. In contrast, eCos's stub is programmed into target flash and run on the target, and as you know, many of the Cortex-M implementations out there have very limited memory - bytes count. Using a GDB stub on the target is hard enough, without increasing the footprint further with that. So speaking selfishly, it doesn't matter so much about OpenOCD or J-link compared to things which are programmed directly onto hardware, which are harder to change. They won't care as much about the format as it's easier for them to adapt. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ** Visit us at NEW:UK - the UK Embedded & Electronics Exhibition ** ** ARM Partner Pavilion/Stand #114. 18-19 April. Birmingham NEC ** ------["Si fractum non sit, noli id reficere"]------ Opinions==mine