From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 989 invoked by alias); 26 Jun 2012 03:24:21 -0000 Received: (qmail 973 invoked by uid 22791); 26 Jun 2012 03:24:18 -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 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, 26 Jun 2012 03:24:04 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 26 Jun 2012 04:24:03 +0100 Received: from shawin053 ([10.164.2.89]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Jun 2012 04:24:48 +0100 From: "Terry Guo" To: "'Jonathan Larmour'" Cc: "'Pedro Alves'" , "'Ulrich Weigand'" , "'Yao Qi'" , , , "Richard Earnshaw" , "Joey Ye" , "Matthew Gretton-Dann" References: <201206131312.q5DDCUfK028160@d06av02.portsmouth.uk.ibm.com> <4FD9B96C.9020908@redhat.com> <4FDA0543.9030100@eCosCentric.com> <000101cd4dee$db02a030$9107e090$@guo@arm.com> <4FE4A91E.4040300@eCosCentric.com> In-Reply-To: Subject: RE: [RFC] Enable GDB handle compressed target.xml returned by GDB stub Date: Tue, 26 Jun 2012 03:24:00 -0000 Message-ID: <000301cd534b$3dd1e1b0$b975a510$@guo@arm.com> MIME-Version: 1.0 X-MC-Unique: 112062604240300201 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/msg00792.txt.bz2 Hi Jonathan, I read your email again and think your solution is: If stub doesn't return compressedXML+ then We go with plain read Else we go with compressed read If we get NUL reply Then we fall back to plain read If this time my understanding on your solution is correct, I think it does = save effort on round trip by not always round trip. BR, Terry=20 >=20 > > -----Original Message----- > > From: Jonathan Larmour [mailto:jifl@ecoscentric.com] > > Sent: Saturday, June 23, 2012 1:19 AM > > To: Terry Guo > > Cc: Pedro Alves; Ulrich Weigand; 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 > > > > On 19/06/12 08:40, Terry Guo wrote: > > > Jifl wrote: > > >> 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. > > > > > > 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 there is a "Z" doesn't impact their response > behavior. > > > > Then they wouldn't have sent compressedXML+ in their qSupported > > response. > > So they'll continue to work fine. > > > > > But the new "zread" can work because those existing gdb servers do > > > check whether the op is "read". So for "zread", that check will > fail > > > and an error code will be returned to host gdb, thus host gdb knows > > the > > > compressed xml file isn't supported. While for the new stub that > > knows > > > "zread", the compressed xml file will be returned. > > > > Sure, but with my suggestion we save having to implement a new > command > > on > > the remote side, as well as avoiding a round trip of attempting the > > zread, > > failing, and fallback to read every time. > > >=20 > Hi Jonathan, >=20 > Maybe I am not correctly understanding your proposal. Please let me > repeat and feel free to correct me: >=20 > There are a bunch of "qXfer:xxxxx:read" inside GDB such as > qXfer:features:read, qXfer:memory-map:read and so on. All of them are > done by one function named remote_read_qxfer. I think it's better if > all the "qXfer:xxxxx:read" can utilize the support of compressed xml > file. It's possible that stub has compressed xml for > "qXfer:features:read" but has plain xml for "qXfer:memory-map:read". So > IMHO the round trip of attempting is unavoidable. >=20 > With zread solution, the new GDB will do following things: >=20 > Send command "qXfer:xxxxx:zread" to stub > If get NULL reply > Then send normal command "qXfer:xxxxx:read" to stub >=20 > This solution can work with either existing stub or the new stub that > support compressed xml file. >=20 > For your solution, I think the round trip attempting is still needed > because stub might return compressed xml and plain xml file. Since we > always need the round trip, then I think it might not be important that > whether stub can return compressedXML+. >=20 > BR, > Terry