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: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, Terry Guo <terry dot guo at arm dot com>, Yao Qi <yao at codesourcery dot com>, gdb-patches at sourceware dot org, tromey at redhat dot com, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Joey Ye <Joey dot Ye at arm dot com>
- Date: Thu, 14 Jun 2012 16:37:39 +0100
- Subject: Re: [RFC] Enable GDB handle compressed target.xml returned by GDB stub
- References: <201206131312.q5DDCUfK028160@d06av02.portsmouth.uk.ibm.com> <4FD9B96C.9020908@redhat.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