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: "Terry Guo" <terry dot guo at arm dot com>
- To: "'Jonathan Larmour'" <jifl at ecoscentric dot com>
- Cc: "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>, "'Pedro Alves'" <palves at redhat dot com>, "Joey Ye" <Joey dot Ye at arm dot com>, "Ulrich Weigand" <uweigand at de dot ibm dot com>
- Date: Wed, 13 Jun 2012 09:57:17 +0800
- Subject: RE: [RFC] Enable GDB handle compressed target.xml returned by GDB stub
- References: <201206121256.q5CCua79003559@d06av02.portsmouth.uk.ibm.com> <4FD76D1D.6080603@eCosCentric.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