From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4043 invoked by alias); 26 Apr 2012 23:22:39 -0000 Received: (qmail 4035 invoked by uid 22791); 26 Apr 2012 23:22:39 -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, 26 Apr 2012 23:22:26 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E61802F7800C; Fri, 27 Apr 2012 00:22:24 +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 t+1qJVErplZz; Fri, 27 Apr 2012 00:22:19 +0100 (BST) Received: from lert.jifvik.org (jifvik.dyndns.org [85.158.45.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: jlarmour@ecoscentric.com) by mail.ecoscentric.com (Postfix) with ESMTP id 006772FB082C; Fri, 27 Apr 2012 00:22:18 +0100 (BST) Message-ID: <4F99D8A5.8050702@eCosCentric.com> Date: Thu, 26 Apr 2012 23:40:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: Tom Tromey 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> <4F95FA8C.7000509@eCosCentric.com> <87ipgm70cc.fsf@fleche.redhat.com> In-Reply-To: <87ipgm70cc.fsf@fleche.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/msg00972.txt.bz2 On 26/04/12 20:35, Tom Tromey wrote: >>>>>> "Jifl" == Jonathan Larmour writes: > > Jifl> Adding code > Jifl> and const data to send back the description for a vanilla Cortex-M > Jifl> profile target has added 1252 bytes to our GDB stub's > Jifl> footprint. If the VFP regs description is added to that, that adds > Jifl> another 931 bytes to give 2183 bytes. That's a big penalty. > > Can the XML be compressed? > I don't know. If not, what if it could be? I assume you mean having it in the stub in a pre-compressed form; in which case yes, that helps[1]. If you meant compressing at runtime at the point of sending, that would mean having to include something zlib-y in the program, which would then add to footprint, which is why I was initially suggesting some sort of encoding of the information required (not merely encoding the XML) rather than just compression. That would be complex though. But if GDB could handle compressed target descriptions, that would be useful. Perhaps the stub could use a different $qSupported response to indicate its compressed, or perhaps GDB could recognise magic numbers at the start of a $qXfer:features:read response and pass to zlib. (e.g. gzip is always 0x1f,0x8b). > I'm curious what you use for your stub. > Based on the recent gdb@ threads, it seems like it can't be gdbserver. There's a stub as part of eCos. It originally was used in Cygnus, but according to its headers came from HP before that. Of course it's been hacked on a lot in eCos so may be quite different to the original now. Jifl [1] Using an xml file defining just the main GPRs for Cortex-M as an example, gzip -9 compresses that from 674 bytes to 237 bytes. Add in the VFP regs and it goes from 1551 bytes to 330. Evidently the additional code overhead to deal with parsing and handling sending the target description is about 600 bytes, with Thumb-2 anyway.