From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9958 invoked by alias); 14 Jun 2012 15:38:03 -0000 Received: (qmail 9778 invoked by uid 22791); 14 Jun 2012 15:38:01 -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, 14 Jun 2012 15:37:47 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 977582FF0004; Thu, 14 Jun 2012 16:37:45 +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 Hzagj7oVBKyl; Thu, 14 Jun 2012 16:37:40 +0100 (BST) Message-ID: <4FDA0543.9030100@eCosCentric.com> Date: Thu, 14 Jun 2012 15:38: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: Ulrich Weigand , Terry Guo , 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> <4FD9B96C.9020908@redhat.com> In-Reply-To: <4FD9B96C.9020908@redhat.com> Content-Type: text/plain; charset=UTF-8 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/msg00472.txt.bz2 On 14/06/12 11:14, Pedro Alves wrote: > > That sounds fine. It makes gdb roundtrip to the target twice as > much for tdescs in the limit, but maybe that doesn't matter in > practice. We could still add the qSupported compressedXML+ aspect so that GDB won't even try if the stub doesn't say it's going to do it. > But note this scheme only works because we're fetching named xml files. > What of other xml objects that aren't filename based? I guess it's > plausible that we'll find other situations where compressing xml > data would be useful. Although it's meant to be a stream not a file as such - think of it more like a protocol issue than a file transfer. And so far we've only been talking about qXfer:features:read which is specific to target descriptions (according to documented behaviour anyway). But hopefully this is irrelevant..... > In that perspective, something like the > 'try qXfer:features:zread:target.xml first, then > qXfer:features:read:target.xml, etc.' alternative sounded attractive. > Or should we not bother? I have a fresh variant proposal derived from the existing suggestions which I think can accommodate all the concerns: 1) Remote stub can return compressedXML+ in qSupported response 2) The current syntax of qXfer:features:read is: qXfer:features:read:ANNEX:OFFSET,LENGTH I suggest instead: qXfer:features:read:ANNEX:OFFSET,LENGTH[,Z] where the ,Z is only attempted if the stub supports the compressedXML remote protocol feature. 3) GDB will attempt to do the read with the ",Z". If the stub returns a NUL character (the standard approach for unsupported packets in the remote protocol), then GDB retries with just the normal request for plaintext: qXfer:features:read:ANNEX:OFFSET,LENGTH This can in fact then be applied to all qXfer:*:read primitives if desired, although I doubt it's useful for many at present. But since every qXfer request goes through remote_read_qxfer() if anything it's easier to support them all, than not to. Anyone got a better proposal? Presumably, by analogy, the equivalent should be put in place for qXfer:*:write and remote_write_qxfer() I guess. And just in response to a mail by Terry: > How about just the .z, like > "qXfer:features:read:target.xml.z" which means the host gdb is trying to > request something compressed by zlib? If the above proposal isn't supported and instead we do use an extension to do this, then I suggest avoiding .z as that is too similar to the .Z standard unix compress format extension, especially when you consider people being used to case-insensitive filenames on certain OS's. 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