From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29941 invoked by alias); 11 Jun 2012 14:43:16 -0000 Received: (qmail 29673 invoked by uid 22791); 11 Jun 2012 14:43: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; Mon, 11 Jun 2012 14:42:56 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 925D42F78006; Mon, 11 Jun 2012 15:42: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 0HToD7OT6lUL; Mon, 11 Jun 2012 15:42:49 +0100 (BST) Message-ID: <4FD603E8.1050000@eCosCentric.com> Date: Mon, 11 Jun 2012 14:43: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, tromey@redhat.com, Richard Earnshaw , 'Pedro Alves' , Joey Ye , uweigand@de.ibm.com Subject: Re: [RFC] Enable GDB handle compressed target.xml returned by GDB stub References: <000601cd47a4$33bf34f0$9b3d9ed0$@guo@arm.com> In-Reply-To: <000601cd47a4$33bf34f0$9b3d9ed0$@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/msg00281.txt.bz2 On 11/06/12 08:31, Terry Guo wrote: > [snip] So a practical solution for such stub is to use the content > of pre-compressed target.xml file and reply host gdb with that > content. To cope with such compressed xml file, I am going to propose > following working model: > 1). Use ZLIB to compress (at Z_BEST_COMPRESSION level) and decompress > the xml file in memory, don't use the gz format. That's fine. > 2). When reply to host gdb, the first four bytes of the packet should > be "ZLIB" and following four bytes should be the length of data before > compressed, the rest should be the compressed data. In this way, the > host gdb can know the format of received data and how to decompress > them. We have to be concerned about compatibility here. I suspect current and older GDBs may get awfully confused by a stub which just goes ahead and returns compressed data instead of XML. It would be better to send nothing and let GDB fall back on guesswork, than send compressed XML to a GDB which can't support it. It may want some variation on the qSupported "qXfer:features:read" response instead. I'll defer to GDB maintainers in the choice, but perhaps qXfer:features:zread ? [snip] > Some results from experiment: > If we use a string to store the plain xml file as below, the size of > the string is 1869 bytes. [snip] > The size of compressed data is 462 bytes. > > So Jonathan: is this size acceptable to eCos stub? Yes that's a big improvement. While I would still prefer the overhead to be 0, this may have to be the best compromise. 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