From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13174 invoked by alias); 13 Jun 2012 13:42:23 -0000 Received: (qmail 12918 invoked by uid 22791); 13 Jun 2012 13:42:20 -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; Wed, 13 Jun 2012 13:41:52 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id CF74B3F70002; Wed, 13 Jun 2012 14:41:50 +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 PnL9cTVCdrJX; Wed, 13 Jun 2012 14:41:47 +0100 (BST) Message-ID: <4FD8989A.3020501@eCosCentric.com> Date: Wed, 13 Jun 2012 13:42: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: Yao Qi , gdb-patches@sourceware.org, tromey@redhat.com, Richard Earnshaw , 'Pedro Alves' , Joey Ye , Ulrich Weigand Subject: Re: [RFC] Enable GDB handle compressed target.xml returned by GDB stub References: <201206121256.q5CCua79003559@d06av02.portsmouth.uk.ibm.com> <4FD76D1D.6080603@eCosCentric.com> <000001cd4907$fd86a1b0$f893e510$@guo@arm.com> In-Reply-To: <000001cd4907$fd86a1b0$f893e510$@guo@arm.com> Content-Type: text/plain; charset=windows-1252 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-06/txt/msg00402.txt.bz2 On 13/06/12 02:57, Terry Guo wrote: >> From: Jonathan Larmour [mailto:jifl@ecoscentric.com] >> >> For what it's worth, that sounds appealing to me. Strictly Terry's >> proposal wasn't a .true gz file but a gzipped stream. But that's >> easy to avoid if we just choose to use the name convention >> target.xmlz or suchlike. > > I am kind of lost on "gz file". Do you mean there is a real gz file and the > stub will do following things to response host gdb request? > > 1. stub open the real gz file and read it into buffer. > 2. stub transmit the buffer to host gdb. > 3. stub close the file No I thought in your initial message you were proposing a zlib compressed stream, rather than a .gz file (which includes the gz file header/footer). I think that proposal is better because it's true that the only things really needed are the zlib compressed stream and the length. No .gz files would be involved at all. So calling it target.xml.gz would be misleading since it wouldn't contain the gzip header/footer required to make it a true .gz format file. > I looked into some open source gdb servers like openocd and stlink. I found > they just use a string to store the content of xml file, they don't have a > real xml file. I think this way consumes less flash space because it doesn't > need store big gz file header. Flash space isn't an issue for openOCD or ST-link. But yes, what I would hope the end result woudl permit is that the target should only need to hold a const char[] containing the compressed xml data, and the decompressed size. 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