Sorry for bringing this old thread up (no pun intended). This code got a few minutes of my attention after I browsed through the clang static analysis report someone posted recently. rtos.c was one of the first in the list, and while the bug report probably was a false positive, I noticed some serious problems with this code. To be honest, I can't see how it could work at all.
The mode variable is repeatedly bit manipulated in ways that can hardly leave any bits set at all. Further, the reply string is repeatedly written over so the reply will probably be nonsense, or at least not what gdb asked for. If this code actually does something useful, please stop me, otherwise I'll simply purge the qP code from rtos.c. /Andreas On Sat, Aug 27, 2011 at 5:01 PM, Jie Zhang <jzhang...@gmail.com> wrote: > Hi Evan, > > If qThreadExtraInfo is not implemented, qP will be used. But since > qThreadExtraInfo has now been implemented, qP should not be needed any > more. GDB added qThreadExtraInfo more than 10 years ago. All GDB > releases since 5.0 will not send out qP packet if the stub supports > qThreadExtraInfo. So I think it's safe for OpenOCD to remove qP > support and only keep qThreadExtraInfo. This will make code clean and > reduce maintenance effort. > > Regards, > Jie > > On Thu, Aug 25, 2011 at 8:50 PM, Evan Hunter <e...@ozhiker.com> wrote: > > Backward compatibility is the reason - > > When I was testing with GDB+eclipse I found that OpenOCD received "qP" > > packets sometimes, and I think I implemented it first, before reading > that > > same quotation you mentioned. Then when I implemented qThreadExtraInfo, I > > figured it was nicer to keep "qP" compatibility too. > > > > Regards, > > > > Evan > > > > > > > > > > Quoting Jie Zhang <jzhang...@gmail.com>: > > > >> Hi Evan, > >> > >> GDB manual says about "qP": > >> > >> Don't use this packet; use the `qThreadExtraInfo' query instead (see > >> below). > >> > >> Since "qThreadExtraInfo" is already supported in rtos.c, why "qP" is > >> still needed? > >> > >> Regards, > >> Jie > >> _______________________________________________ > >> Openocd-development mailing list > >> Openocd-development@lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/openocd-development > >> > > > > > > > > > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development >
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
