From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28138 invoked by alias); 13 Jun 2012 13:47:22 -0000 Received: (qmail 28126 invoked by uid 22791); 13 Jun 2012 13:47:21 -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:47:08 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id A0FFF3770006; Wed, 13 Jun 2012 14:47:07 +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 Y9dc60t-yK1q; Wed, 13 Jun 2012 14:47:04 +0100 (BST) Message-ID: <4FD899D8.7080903@eCosCentric.com> Date: Wed, 13 Jun 2012 13:47: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: Ulrich Weigand CC: Terry Guo , 'Pedro Alves' , Yao Qi , gdb-patches@sourceware.org, tromey@redhat.com, Richard Earnshaw , Joey Ye Subject: Re: [RFC] Enable GDB handle compressed target.xml returned by GDB stub References: <201206131312.q5DDCUfK028160@d06av02.portsmouth.uk.ibm.com> In-Reply-To: <201206131312.q5DDCUfK028160@d06av02.portsmouth.uk.ibm.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-06/txt/msg00403.txt.bz2 On 13/06/12 14:12, Ulrich Weigand wrote: > Terry Guo wrote: > >> Yes, we need to consider xi:includes which means we have to involve a >> global state. > > Not necessarily; the way I had intended my suggestion to work was that > GDB always adds ".gz" (or some other suffix if we actually are not > compatible with the .gz file format) to *every* file it fetches, not > just to the initial target.xml, but also to other files fetched via > xi:include statements ... > > If the compressed version of the file is not available, GDB would > then fall back to the original file name (on a file-by-file basis). I agree. This also means that the target can choose whether to return any file as compressed or not, rather than having to have everything compressed from then on, even if some XML files might take up more space compressed than uncompressed, or might need to be generated - but not all files. It's getting a bit hypothetical at this point, it's true, but not unreasonably so. 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