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

["Terry Guo" <terry.guo@arm.com>]

> -----Original Message-----
> From: Jonathan Larmour [mailto:jifl@ecoscentric.com]
> Sent: Wednesday, June 13, 2012 12:24 AM
> To: Ulrich Weigand
> Cc: Yao Qi; Terry Guo; gdb-patches@sourceware.org; tromey@redhat.com;
> Richard Earnshaw; 'Pedro Alves'; Joey Ye
> Subject: Re: [RFC] Enable GDB handle compressed target.xml returned by
> GDB stub
> 
> On 12/06/12 13:56, Ulrich Weigand wrote:
> > Yao Qi wrote:
> >> I'd like GDB keeps using qXfer:features:read:target.xml to fetch the
> xml
> >> file, even it is compressed.  We need some changes on qSupported in
> both
> >> sides,
> >
> > That still makes the result of qXfer:features:read:target.xml
> dependent
> > on global state ...   Why not simply support compressed files by
> having
> > the stub respond to
> >    qXfer:features:read:target.xml.gz
> > (etc) if it has a compressed file image?
> >
> > Optionally we might still add a qSupported feature as you describe;
> > otherwise GDB might just probe whether the stub knows .gz files.
> 
> 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.
> 
> Jifl

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

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.

BR,
Terry