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

["Terry Guo" <terry dot guo at arm dot com>]

> -----Original Message-----
> From: Jonathan Larmour [mailto:jifl@ecoscentric.com]
> Sent: Saturday, June 23, 2012 1:19 AM
> To: Terry Guo
> Cc: Pedro Alves; Ulrich Weigand; Yao Qi; gdb-patches@sourceware.org;
> tromey@redhat.com; Richard Earnshaw; Joey Ye
> Subject: Re: [RFC] Enable GDB handle compressed target.xml returned by
> GDB stub
> 
> On 19/06/12 08:40, Terry Guo wrote:
> > Jifl wrote:
> >> 1) Remote stub can return compressedXML+ in qSupported response
> >>
> >> 2) The current syntax of qXfer:features:read is:
> >> qXfer:features:read:ANNEX:OFFSET,LENGTH I suggest instead:
> >> qXfer:features:read:ANNEX:OFFSET,LENGTH[,Z] where the ,Z is only
> >> attempted if the stub supports the compressedXML remote protocol
> >> feature.
> >
> > I don't think it will work after I looked into some open source GDB
> > servers like STLINk, OpenOCD. After they confirm that the packet is
> > qXfer:features:read, they just extract information of ANNEX, OFFSET
> and
> > LENGTH. Whether there is a "Z" doesn't impact their response behavior.
> 
> Then they wouldn't have sent compressedXML+ in their qSupported
> response.
> So they'll continue to work fine.
> 
> > But the new "zread" can work because those existing gdb servers do
> > check whether the op is "read". So for "zread", that check will fail
> > and an error code will be returned to host gdb, thus host gdb knows
> the
> > compressed xml file isn't supported. While for the new stub that
> knows
> > "zread", the compressed xml file will be returned.
> 
> Sure, but with my suggestion we save having to implement a new command
> on
> the remote side, as well as avoiding a round trip of attempting the
> zread,
> failing, and fallback to read every time.
> 

Hi Jonathan,

Maybe I am not correctly understanding your proposal. Please let me repeat and feel free to correct me:

There are a bunch of "qXfer:xxxxx:read" inside GDB such as qXfer:features:read, qXfer:memory-map:read and so on. All of them are done by one function named remote_read_qxfer. I think it's better if all the "qXfer:xxxxx:read" can utilize the support of compressed xml file. It's possible that stub has compressed xml for "qXfer:features:read" but has plain xml for "qXfer:memory-map:read". So IMHO the round trip of attempting is unavoidable.

With zread solution, the new GDB will do following things:

   Send command "qXfer:xxxxx:zread" to stub
   If get NULL reply
   Then send normal command "qXfer:xxxxx:read" to stub

This solution can work with either existing stub or the new stub that support compressed xml file.

For your solution, I think the round trip attempting is still needed because stub might return compressed xml and plain xml file. Since we always need the round trip, then I think it might not be important that whether stub can return compressedXML+.

BR,
Terry