This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



> >
> > So the whole process can be simplified to:
> >
> > Step 1: GDB just sends "qXfer:features:read:target.xml.gz" to stub to
> try to
> > get a compressed xml file.
> > Step 2: If stub supports compressed xml, then it sends it to GDB.
> Otherwise
> > nothing get replied.
> > Step 3: If GDB gets something, then it proceeds to decompress the xml
> file
> > and go ahead. If get nothing, GDB sends "
> qXfer:features:read:target.xml" to
> > try to request the plain xml file.
> >
> > For GDB that doesn't support compressed xml file, the
> > "qXfer:features:read:target.xml.gz" will never be used.
> >
> > How about the above model?
> 
> 
> Please don't consider only target.xml in the design, but also the
> xi:includes.
> 

Yes, we need to consider xi:includes which means we have to involve a global state. A refine to Yao's solution:

1. If host GDB support compressed xml file, then it sends "$qSupported:multiprocess+;qRelocInsn;compressedXML+" to stub. Here is a new feature compressedXML+.

2. If stub supports compressed xml file and will reply with compressed xml file, then it replies with ";compressedXML+" to GDB.

3. We still use "$qXfer:features:read:target.xml" to request xml file as usual, including the file in "xi:includes". For stub that returns ";compressedXML+", the gdb will assume all the returned xml file are compressed.

4. Otherwise the returned data are not compressed.

BR,
Terry



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]