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

[Jonathan Larmour <jifl at eCosCentric dot com>]

On 14/06/12 11:14, Pedro Alves wrote:
> 
> That sounds fine.  It makes gdb roundtrip to the target twice as
> much for tdescs in the limit, but maybe that doesn't matter in
> practice.

We could still add the qSupported compressedXML+ aspect so that GDB won't
even try if the stub doesn't say it's going to do it.

> But note this scheme only works because we're fetching named xml files.
> What of other xml objects that aren't filename based? I guess it's
> plausible that we'll find other situations where compressing xml
> data would be useful.

Although it's meant to be a stream not a file as such - think of it more
like a protocol issue than a file transfer. And so far we've only been
talking about qXfer:features:read which is specific to target descriptions
(according to documented behaviour anyway). But hopefully this is
irrelevant.....

> In that perspective, something like the
> 'try qXfer:features:zread:target.xml first, then
> qXfer:features:read:target.xml, etc.' alternative sounded attractive.
> Or should we not bother?

I have a fresh variant proposal derived from the existing suggestions
which I think can accommodate all the concerns:

1) Remote stub can return compressedXML+ in qSupported response

2) The current syntax of qXfer:features:read is:
     qXfer:features:read:ANNEX:OFFSET,LENGTH
I suggest instead:
     qXfer:features:read:ANNEX:OFFSET,LENGTH[,Z]
where the ,Z is only attempted if the stub supports the compressedXML
remote protocol feature.

3) GDB will attempt to do the read with the ",Z". If the stub returns a
NUL character (the standard approach for unsupported packets in the remote
protocol), then GDB retries with just the normal request for plaintext:
     qXfer:features:read:ANNEX:OFFSET,LENGTH


This can in fact then be applied to all qXfer:*:read primitives if
desired, although I doubt it's useful for many at present. But since every
qXfer request goes through remote_read_qxfer() if anything it's easier to
support them all, than not to.

Anyone got a better proposal?

Presumably, by analogy, the equivalent should be put in place for
qXfer:*:write and remote_write_qxfer() I guess.

And just in response to a mail by Terry:
>  How about just the .z, like
> "qXfer:features:read:target.xml.z" which means the host gdb is trying to
> request something compressed by zlib?

If the above proposal isn't supported and instead we do use an extension
to do this, then I suggest avoiding .z as that is too similar to the .Z
standard unix compress format extension, especially when you consider
people being used to case-insensitive filenames on certain OS's.

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