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

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

> 
> > In that perspective, something like the
> > 'try qXfer:features:zread:target.xml first, then
> > qXfer:features:read:target.xml, etc.' alternative sounded attractive.
> > Or should we not bother?
> 
> I have a fresh variant proposal derived from the existing suggestions
> which I think can accommodate all the concerns:
> 
> 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.

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.

BR,
Terry