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
...@fritiofson.net [mailto:andr...@fritiofson.net] On Behalf Of
Andreas Fritiofson
Sent: Thursday, 20 October 2011 9:13 AM
To: Jie Zhang
Cc: Evan Hunter; Evan Hunter; openocd-development
Subject: Re: [Openocd-development] Remove qP from rtos code?
Sorry for bringing this old thread up (no pun intended
Hi!
On Thu, Oct 20, 2011 at 12:47 AM, Evan Hunter ehun...@broadcom.com wrote:
You are right – Looking at it again, the “qP” code looks like I got halfway
through implementing it, then found that I should be using qThreadExtraInfo
instead.
Please feel free to remove it. The only reason I
Ping.
Jie
On Sat, Aug 27, 2011 at 11:01 AM, 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
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.
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
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
