From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19510 invoked by alias); 24 Apr 2012 00:58:16 -0000 Received: (qmail 19501 invoked by uid 22791); 24 Apr 2012 00:58:14 -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; Tue, 24 Apr 2012 00:57:57 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E1BFC2F78006; Tue, 24 Apr 2012 01:57:54 +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 f4nRIsI5zUMq; Tue, 24 Apr 2012 01:57:49 +0100 (BST) Message-ID: <4F95FA8C.7000509@eCosCentric.com> Date: Tue, 24 Apr 2012 02:49: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: Pedro Alves 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> <4F91593B.4020309@redhat.com> In-Reply-To: <4F91593B.4020309@redhat.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/msg00760.txt.bz2 On 20/04/12 13:40, Pedro Alves wrote: > > 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. I don't think that's unreasonable for a principle, but as I mentioned elsewhere, some of these targets are very resource constrained. Bytes really do count. I know it's not ideal, but on the other hand I hope that there aren't going to be that many layouts to support, and this argument only really applies to the processors which tend to be very resource-limited, not big x86 or PowerPC chips. > 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. Sorry it's taken me a few days to get back to you, but I've been implementing what's required to send the XML target description support in the eCos stub, so that I could have hard data. Unfortunately it has confirmed my suspicions. Adding code and const data to send back the description for a vanilla Cortex-M profile target has added 1252 bytes to our GDB stub's footprint. If the VFP regs description is added to that, that adds another 931 bytes to give 2183 bytes. That's a big penalty. XML is not exactly concise. Theoretically we could try and create some sort of encoding to programmatically generate the XML instead on a dynamic basis, but that's quite a complex thing to be forced to do, and not scalable. Unfortunately, in retrospect I'm not sure XML was really the best format for sending important information from stub to host. It might save a bit if it were possible for a stub to include XML files located on the debugging host, but GDB currently assumes any referenced inclusions must only be read from the target with another qXfer. Maybe the current feature XML files could be installed by GDB somewhere central, and be able to be looked up according to some path setting. But even if this is a good idea, obviously it's only theoretical now. I'm not sure it would save enough, but it would help. I understand that for host gdbservers and beefy targets, sending target descriptions is easy and a good thing; but we can't lose sight of the fact that many modern System-on-Chips are not like that, and Cortex-M targets fall into that category. I wouldn't expect to put a GDB stub on the smallest Cortex-M I've seen with only 16K flash and 4K RAM, but once you're talking about 64K, it may become more feasible, and little changes make a big difference. > 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. I'll fix those. How would you like to move forward? 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. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine