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

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

Hi Jonathan,

I read your email again and think your solution is:

  If stub doesn't return compressedXML+ then
    We go with plain read
  Else we go with compressed read
     If we get NUL reply
        Then we fall back to plain read

If this time my understanding on your solution is correct, I think it does save effort on round trip by not always round trip.

BR,
Terry 


> 
> > -----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