From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30923 invoked by alias); 19 Jun 2012 07:40:31 -0000 Received: (qmail 30817 invoked by uid 22791); 19 Jun 2012 07:40:30 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,MSGID_MULTIPLE_AT,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_NO,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Jun 2012 07:40:16 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 19 Jun 2012 08:40:15 +0100 Received: from shawin053 ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Jun 2012 08:40:50 +0100 From: "Terry Guo" To: "'Jonathan Larmour'" , "Pedro Alves" Cc: "Ulrich Weigand" , "Yao Qi" , , , "Richard Earnshaw" , "Joey Ye" References: <201206131312.q5DDCUfK028160@d06av02.portsmouth.uk.ibm.com> <4FD9B96C.9020908@redhat.com> <4FDA0543.9030100@eCosCentric.com> In-Reply-To: <4FDA0543.9030100@eCosCentric.com> Subject: RE: [RFC] Enable GDB handle compressed target.xml returned by GDB stub Date: Tue, 19 Jun 2012 07:40:00 -0000 Message-ID: <000101cd4dee$db02a030$9107e090$@guo@arm.com> MIME-Version: 1.0 X-MC-Unique: 112061908401500701 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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/msg00606.txt.bz2 >=20 > > 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? >=20 > I have a fresh variant proposal derived from the existing suggestions > which I think can accommodate all the concerns: >=20 > 1) Remote stub can return compressedXML+ in qSupported response >=20 > 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. >=20 I don't think it will work after I looked into some open source GDB servers= like STLINk, OpenOCD. After they confirm that the packet is qXfer:features= :read, they just extract information of ANNEX, OFFSET and LENGTH. Whether t= here is a "Z" doesn't impact their response behavior. But the new "zread" can work because those existing gdb servers do check wh= ether the op is "read". So for "zread", that check will fail and an error c= ode will be returned to host gdb, thus host gdb knows the compressed xml fi= le isn't supported. While for the new stub that knows "zread", the compress= ed xml file will be returned. BR, Terry