From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25022 invoked by alias); 19 Apr 2012 14:17:53 -0000 Received: (qmail 25014 invoked by uid 22791); 19 Apr 2012 14:17:51 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,TW_VF,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 14:17:18 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 9F0CD2F78003; Thu, 19 Apr 2012 15:17:16 +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 uVsV5SVTZ1Iq; Thu, 19 Apr 2012 15:17:11 +0100 (BST) Message-ID: <4F901E66.9030700@eCosCentric.com> Date: Thu, 19 Apr 2012 14:17: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: palves@redhat.com, Joey Ye , Matthew Gretton-Dann , gdb@sourceware.org Subject: Re: [RFC] Support ARMv7M FPU registers in GDB References: <000401cd1ddf$432170f0$c96452d0$@guo@arm.com> In-Reply-To: <000401cd1ddf$432170f0$c96452d0$@guo@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00151.txt.bz2 Hi Terry, On 19/04/12 04:48, Terry Guo wrote: > > The ARM Cortex-M4 processor is based on ARMv7M architecture and enhanced by > its DSP extension and Floating Point Unit. As more and more M4 based boards > are emerging in the market, I would like to propose following solution for > GDB to support the access of FPU registers. > > 1). I studied how the GDB support other Cortex-M core like Cortex-M3 and > noticed that the GDB has to use "g_packet_guess" mechanism to maintain > compatibility. I don't know why some gdb stubs return faked FPA registers > and some don't. Because of the history of the initial Cortex-M development being just a variant of ARM. The XPSR was treated as a tweaked CPSR and so on. So in the first instance the register format used by stubs didn't change from the ARM default. The target description support was also quite new at that point. > But as M4 board are all recently released board, so maybe it > is time for M4 gdb stub to return a correct g packet: 16 core registers + > xpsr register + 16 double precision FPU registers + fpscr register. Does > this expectation make sense? Is it possible for gdb stub to do so? Yes, and I have already been developing a patch to do exactly this - I had been waiting for confirmation from someone I was working with that it worked fine, and as it happens I've just had that. > 2). The GDB is going to need a new target description file to describe M4 > register layout. I propose arm-with-m-fpu.xml for its filename. For file > content, it just includes another two existing xml files arm-m-profile.xml > and arm-vfpv2.xml. Maybe since you're in ARM you have a better idea of the future product roadmap (and we're talking _years_ into the future here), but I have named it arm-with-m-vfp-d16, because Cortex-M4 uses the VFPv4 single precision 16d regs layout (corresponding to -mfpu=fpv4-sp-d16 in GCC). That is different from VFP units with other cores. I could conceive of future Cortex-M's coming out with a wider variety of FPU layouts than just that, such as the full VFPv4. > 3). In function arm_gdbarch_init, I propose to add more checks where we > check whether the target is cortex-m. At this point, once the gdb figures > out the target is cortex-m4 from the ELF attributes, we then set the tdesc > to tdesc_arm_with_m_fpu. Although you need to be aware that just because someone built the program with -mcpu=cortex-m4, it doesn't mean they wanted to use hardware floating point. Hardware FPU use can have hardware context switch consequences that some people would be sensitive to. For that reason, my patch actually only added a new 'g' packet guess based on the size of the stub's response: + /* M-profile plus M4F VFP. */ + register_remote_g_packet_guess (gdbarch, + /* r0-r12,sp,lr,pc; d0-d15; fpscr,xpsr */ + (16 * INT_REGISTER_SIZE) + + (16 * VFP_REGISTER_SIZE) + + (2 * INT_REGISTER_SIZE), + tdesc_arm_with_m_vfp_d16); > 4). No need to describe the single precision FPU registers in XML file > because the GDB will handle them as aliases of double precision format. Correct. > 5). According to M4 Debug architecture, there is a pretty straight way for > stub to access FPU registers in single precision format. But there is no > direct way to access FPU registers in double precision format. So one more > thing for GDB stub is that the stub needs to do more work to construct > double precision register from two single precision registers. Since that is just concatenation, I'm not sure I see any real issue? > Is this proposal good enough? Please feel free to comment. And any of them > are welcomed. I will submit my patch for discussion to the gdb-patches list in a moment. Perhaps you might like to have a look when it's there and see what you think. 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