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: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Terry Guo <terry dot guo at arm dot com>, 'Pedro Alves' <palves at redhat 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: Wed, 13 Jun 2012 14:47:04 +0100
- Subject: Re: [RFC] Enable GDB handle compressed target.xml returned by GDB stub
- References: <201206131312.q5DDCUfK028160@d06av02.portsmouth.uk.ibm.com>
On 13/06/12 14:12, 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).
I agree.
This also means that the target can choose whether to return any file as
compressed or not, rather than having to have everything compressed from
then on, even if some XML files might take up more space compressed than
uncompressed, or might need to be generated - but not all files. It's
getting a bit hypothetical at this point, it's true, but not unreasonably so.
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