From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26763 invoked by alias); 11 Jun 2012 07:31:13 -0000 Received: (qmail 26738 invoked by uid 22791); 11 Jun 2012 07:31:11 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_20,KHOP_RCVD_UNTRUST,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; Mon, 11 Jun 2012 07:30:56 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Mon, 11 Jun 2012 08:30:54 +0100 Received: from shawin053 ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 11 Jun 2012 08:31:19 +0100 From: "Terry Guo" To: "Jonathan Larmour" Cc: , , "Richard Earnshaw" , "'Pedro Alves'" , "Joey Ye" , Subject: [RFC] Enable GDB handle compressed target.xml returned by GDB stub Date: Mon, 11 Jun 2012 07:31:00 -0000 Message-ID: <000601cd47a4$33bf34f0$9b3d9ed0$@guo@arm.com> MIME-Version: 1.0 X-MC-Unique: 112061108305406501 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/msg00271.txt.bz2 Hi, As stated in GDB document, the most natural way for gdb to get target register information is the target.xml file returned from gdb server or gdb stub. Normally it wouldn't be a burden for gdb server/stub to implement such feature, but there are some gdb stubs running directly on bare metal boards which have very limited memory/flash resources, saving the content of target.xml file means extra storage and cost increment. So a practical solution for such stub is to use the content of pre-compressed target.xml file and reply host gdb with that content. To cope with such compressed xml file, I am going to propose following working model: 1). Use ZLIB to compress (at Z_BEST_COMPRESSION level) and decompress the xml file in memory, don't use the gz format. 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. I am not going to propose to adding a new feature in gdb remote serial protocol because it is possible that a gdb server/stub can support both ways. In addition gdb needs to know the length of uncompressed data. Anyway we need to detect the received data to figure out its actual format. So I plan to implement such functionality as an extension of how gdb handle received xml file. Perhaps the right place for this functionality is right after the call of function fetch_available_features_from_target in function target_read_description_xml. Please share your thoughts and comments. All of them are welcomed. PS:=20 Related background is here: http://sourceware.org/ml/gdb-patches/2012-04/msg00971.html. 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. static const char *raw_target_xml =3D "" "" "" "" "" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " "" "" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " "" "" ; Then compress it with zlib function: ret =3D compress2((Bytef*)dest, (uLongf *)&dlen, (const Bytef *)raw_target_xml, (uLong)mlen, Z_BEST_COMPRESSION); The size of compressed data is 462 bytes. So Jonathan: is this size acceptable to eCos stub? BR, Terry