From: "Terry Guo" <terry.guo@arm.com>
To: "Jonathan Larmour" <jifl@eCosCentric.com>
Cc: <gdb-patches@sourceware.org>, <tromey@redhat.com>,
"Richard Earnshaw" <Richard.Earnshaw@arm.com>,
"'Pedro Alves'" <palves@redhat.com>, "Joey Ye" <Joey.Ye@arm.com>,
<uweigand@de.ibm.com>
Subject: [RFC] Enable GDB handle compressed target.xml returned by GDB stub
Date: Mon, 11 Jun 2012 07:31:00 -0000 [thread overview]
Message-ID: <000601cd47a4$33bf34f0$9b3d9ed0$@guo@arm.com> (raw)
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:
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 =
"<?xml version=\"1.0\"?>"
"<!-- Copyright (C) 2010, 2011 Free Software Foundation, Inc."
" Copying and distribution of this file, with or without modification,"
" are permitted in any medium without royalty provided the copyright"
" notice and this notice are preserved. -->"
"<!DOCTYPE target SYSTEM \"gdb-target.dtd\">"
"<target>"
"<feature name=\"org.gnu.gdb.arm.m-profile\">"
" <reg name=\"r0\" bitsize=\"32\"/>"
" <reg name=\"r1\" bitsize=\"32\"/>"
" <reg name=\"r2\" bitsize=\"32\"/>"
" <reg name=\"r3\" bitsize=\"32\"/>"
" <reg name=\"r4\" bitsize=\"32\"/>"
" <reg name=\"r5\" bitsize=\"32\"/>"
" <reg name=\"r6\" bitsize=\"32\"/>"
" <reg name=\"r7\" bitsize=\"32\"/>"
" <reg name=\"r8\" bitsize=\"32\"/>"
" <reg name=\"r9\" bitsize=\"32\"/>"
" <reg name=\"r10\" bitsize=\"32\"/>"
" <reg name=\"r11\" bitsize=\"32\"/>"
" <reg name=\"r12\" bitsize=\"32\"/>"
" <reg name=\"sp\" bitsize=\"32\" type=\"data_ptr\"/>"
" <reg name=\"lr\" bitsize=\"32\"/>"
" <reg name=\"pc\" bitsize=\"32\" type=\"code_ptr\"/>"
" <reg name=\"xpsr\" bitsize=\"32\" regnum=\"25\"/>"
"</feature>"
"<feature name=\"org.gnu.gdb.arm.vfp\">"
" <reg name=\"d0\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d1\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d2\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d3\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d4\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d5\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d6\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d7\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d8\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d9\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d10\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d11\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d12\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d13\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d14\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"d15\" bitsize=\"64\" type=\"ieee_double\"/>"
" <reg name=\"fpscr\" bitsize=\"32\" type=\"int\" group=\"float\"/>"
"</feature>"
"</target>"
;
Then compress it with zlib function:
ret = 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
next reply other threads:[~2012-06-11 7:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-11 7:31 Terry Guo [this message]
2012-06-11 14:43 ` Jonathan Larmour
2012-06-12 9:37 ` Terry Guo
2012-06-12 12:44 ` Yao Qi
2012-06-12 12:57 ` Ulrich Weigand
2012-06-12 16:24 ` Jonathan Larmour
2012-06-13 1:58 ` Terry Guo
2012-06-13 13:42 ` Jonathan Larmour
2012-06-14 0:53 ` Terry Guo
2012-06-13 11:57 ` Terry Guo
2012-06-13 12:26 ` Pedro Alves
2012-06-13 12:51 ` Terry Guo
2012-06-13 13:12 ` Ulrich Weigand
2012-06-13 13:47 ` Jonathan Larmour
2012-06-14 1:11 ` Terry Guo
2012-06-14 10:14 ` Pedro Alves
2012-06-14 13:54 ` Joel Brobecker
2012-06-14 14:58 ` Ulrich Weigand
2012-06-14 15:38 ` Jonathan Larmour
2012-06-19 7:40 ` Terry Guo
2012-06-22 17:19 ` Jonathan Larmour
2012-06-26 2:39 ` Terry Guo
2012-06-26 3:24 ` Terry Guo
2012-06-26 11:58 ` Jonathan Larmour
2012-06-27 3:42 ` Terry Guo
2012-06-27 21:25 ` Jonathan Larmour
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='000601cd47a4$33bf34f0$9b3d9ed0$@guo@arm.com' \
--to=terry.guo@arm.com \
--cc=Joey.Ye@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=gdb-patches@sourceware.org \
--cc=jifl@eCosCentric.com \
--cc=palves@redhat.com \
--cc=tromey@redhat.com \
--cc=uweigand@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox