From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20075 invoked by alias); 12 Jun 2012 09:37:35 -0000 Received: (qmail 19695 invoked by uid 22791); 12 Jun 2012 09:37:33 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,MSGID_MULTIPLE_AT,RCVD_IN_DNSWL_LOW 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, 12 Jun 2012 09:37:18 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 12 Jun 2012 10:37:16 +0100 Received: from shawin053 ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Jun 2012 10:37:40 +0100 From: "Terry Guo" To: "'Jonathan Larmour'" Cc: , , "Richard Earnshaw" , "'Pedro Alves'" , "Joey Ye" , References: <000601cd47a4$33bf34f0$9b3d9ed0$@guo@arm.com> <4FD603E8.1050000@eCosCentric.com> In-Reply-To: <4FD603E8.1050000@eCosCentric.com> Subject: RE: [RFC] Enable GDB handle compressed target.xml returned by GDB stub Date: Tue, 12 Jun 2012 09:37:00 -0000 Message-ID: <000001cd487f$0763f450$162bdcf0$@guo@arm.com> MIME-Version: 1.0 X-MC-Unique: 112061210371615401 Content-Type: text/plain; charset=WINDOWS-1252 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/msg00326.txt.bz2 Hi Jonathan, [snip] >=20 > > 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. >=20 > 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. >=20 > 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 ? >=20 Agree. The host gdb should inform stub that whether it can support compressed xml. The qXfer:features:zread is ok to me. > [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? >=20 > Yes that's a big improvement. While I would still prefer the overhead > to > be 0, this may have to be the best compromise. >=20 But if you consider for future, it would be very possible that two different cores share same g reply length. The xml file is still the most reliable and natural way to inform exact target register info to host gdb. I believe you also don't like to add more and more guesses in GDB. BR, Terry