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

[Jonathan Larmour <jifl@eCosCentric.com>]

On 13/06/12 02:57, Terry Guo wrote:
>> From: Jonathan Larmour [mailto:jifl@ecoscentric.com]
>>
>> For what it's worth, that sounds appealing to me. Strictly Terry's 
>> proposal wasn't a .true gz file but a gzipped stream. But that's
>> easy to avoid if we just choose to use the name convention
>> target.xmlz or suchlike.
> 
> I am kind of lost on "gz file". Do you mean there is a real gz file and the
> stub will do following things to response host gdb request?
> 
> 1. stub open the real gz file and read it into buffer.
> 2. stub transmit the buffer to host gdb.
> 3. stub close the file

No I thought in your initial message you were proposing a zlib compressed
stream, rather than a .gz file (which includes the gz file header/footer).
I think that proposal is better because it's true that the only things
really needed are the zlib compressed stream and the length. No .gz files
would be involved at all. So calling it target.xml.gz would be misleading
since it wouldn't contain the gzip header/footer required to make it a
true .gz format file.

> I looked into some open source gdb servers like openocd and stlink. I found
> they just use a string to store the content of xml file, they don't have a
> real xml file. I think this way consumes less flash space because it doesn't
> need store big gz file header.

Flash space isn't an issue for openOCD or ST-link. But yes, what I would
hope the end result woudl permit is that the target should only need to
hold a const char[] containing the compressed xml data, and the
decompressed size.

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