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: "Pedro Alves" <palves at redhat dot com>, "Ulrich Weigand" <uweigand at de dot ibm dot com>, "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>, "Joey Ye" <Joey dot Ye at arm dot com>, "Matthew Gretton-Dann" <Matthew dot Gretton-Dann at arm dot com>
- Date: Tue, 26 Jun 2012 10:39:57 +0800
- Subject: RE: [RFC] Enable GDB handle compressed target.xml returned by GDB stub
- References: <201206131312.q5DDCUfK028160@d06av02.portsmouth.uk.ibm.com> <4FD9B96C.9020908@redhat.com> <4FDA0543.9030100@eCosCentric.com> <000101cd4dee$db02a030$9107e090$@guo@arm.com> <4FE4A91E.4040300@eCosCentric.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