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

["Terry Guo" <terry.guo@arm.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