This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [RFC] Enable GDB handle compressed target.xml returned by GDB stub
- From: "Terry Guo" <terry dot guo at arm dot com>
- To: "'Jonathan Larmour'" <jifl at ecoscentric dot com>
- Cc: <gdb-patches at sourceware dot org>, <tromey at redhat dot com>, "Richard Earnshaw" <Richard dot Earnshaw at arm dot com>, "'Pedro Alves'" <palves at redhat dot com>, "Joey Ye" <Joey dot Ye at arm dot com>, <uweigand at de dot ibm dot com>
- Date: Tue, 12 Jun 2012 17:37:25 +0800
- Subject: RE: [RFC] Enable GDB handle compressed target.xml returned by GDB stub
- References: <000601cd47a4$33bf34f0$9b3d9ed0$@guo@arm.com> <4FD603E8.1050000@eCosCentric.com>
Hi Jonathan,
[snip]
>
> > 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.
>
> 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.
>
> 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 ?
>
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?
>
> Yes that's a big improvement. While I would still prefer the overhead
> to
> be 0, this may have to be the best compromise.
>
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