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: Pedro Alves <palves at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Terry Guo <terry dot guo at arm dot com>, "'Jonathan Larmour'" <jifl at ecoscentric 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 11:14:04 +0100
- Subject: Re: [RFC] Enable GDB handle compressed target.xml returned by GDB stub
- References: <201206131312.q5DDCUfK028160@d06av02.portsmouth.uk.ibm.com>
On 06/13/2012 02:12 PM, Ulrich Weigand wrote:
> Terry Guo wrote:
>
>> Yes, we need to consider xi:includes which means we have to involve a
>> global state.
>
> Not necessarily; the way I had intended my suggestion to work was that
> GDB always adds ".gz" (or some other suffix if we actually are not
> compatible with the .gz file format) to *every* file it fetches, not
> just to the initial target.xml, but also to other files fetched via
> xi:include statements ...
>
> If the compressed version of the file is not available, GDB would
> then fall back to the original file name (on a file-by-file basis).
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.
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. 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?
--
Pedro Alves