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

So the whole process can be simplified to:

Step 1: GDB just sends "qXfer:features:read:target.xml.gz" to stub to try to
get a compressed xml file.
Step 2: If stub supports compressed xml, then it sends it to GDB. Otherwise
nothing get replied.
Step 3: If GDB gets something, then it proceeds to decompress the xml file
and go ahead. If get nothing, GDB sends " qXfer:features:read:target.xml" to
try to request the plain xml file.

For GDB that doesn't support compressed xml file, the
"qXfer:features:read:target.xml.gz" will never be used.

How about the above model?

BR,
Terry