Re: [RFC] Enable GDB handle compressed target.xml returned by GDB stub

[Jonathan Larmour <jifl@eCosCentric.com>]

On 11/06/12 08:31, Terry Guo wrote:
> [snip] 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.

That's fine.

> 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 ?

[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.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine