jasonmolenda added a comment.
For what it's worth, this change was part of the changes we made to reduce
packet traffic for "private stops". When a high-level "step" or "next" command
is done, we instruction step (or fast-step with Jim's fast-step code when it
sees a sequence of instructions that cannot branch - we set a breakpoint and
continue instead of instruction stepping) until we reach the end of the
stepping range and then we do a "public stop". Given that the private stops
are more numerous, we spent a bunch of time looking at everything we could
eliminate for those private stops. Getting all the pc values into the stop
packet (aka T or ? packet) was a big one. For multi-threaded programs we also
added a "jstopinfo" which gives the stop reasons for all threads that had a
stop reason, e.g.
T05thread:90834;threads:90834,90845,90846,90847,90848,90849,9084a,9084b,9084c,9084d,9084e,9084f,90850,90851;thread-pcs:100000ac4,7fffb3eb1fda,7fffb3eb1fda,7fffb3eb1fda,7fffb3eb1fda,7fffb3eb1fda,7fffb3eb1fda,7fffb3eb1fda,7fffb3eb1fda,7fffb3eb1fda,7fffb3eb1fda,7fffb3eb1fda,7fffb3eb1fda,7fffb3eb1fda;jstopinfo:5b7b22746964223a3539313932342c226d6574797065223a362c226d6564617461223a5b322c305d2c22726561736f6e223a22657863657074696f6e227d5d;metype:6;mecount:2;medata:2;medata:0;memory:0x7fff5fbff8e0=30f9bf5fff7f0000b20c000001000000;memory:0x7fff5fbff930=40f9bf5fff7f00005532d8b3ff7f0000;
(I elided the expedited registers)
The jstopinfo above is ascii-hex encoding of the JSON,
[{"tid":591924,"metype":6,"medata":[2,0],"reason":"exception"}]
else lldb would iterate over all the threads to see if any of them stopped for
some reason (e.g. hitting a breakpoint) while we were instruction stepping. If
you don't see lldb doing that thread-stop-reason checking for your platform, it
won't be needed.
(and looking at this, it's giving the stop reasoon for the thread that hit a
breakpoint -- which we already get from the T packet. Hmmm, I see another tiny
perf win in the near future! ;)
We're also sending up 4 words of stack memory which might be the start of this
function's stack frame and it's caller's stack frame. For a simple "find the
pc of the caller stack frame" in lldb, this can remove a couple of memory reads
as the thread stepping logic needs to know who the caller stack frame is.
We also did some work on the public stop side, adding a jThreadsInfo packet
which gives us all the information about all of the threads. We get all the
expedited registers, the thread name, the stop reasons, information about the
darwin libdispatch queues, and expedited stack memory to help speed up a stack
walk (I don't remember offhand if debugserver tries to walk the entire stack
using the simple follow-the-frame-chain-in-stack-memory technique or if it caps
the stack walk. but our main IDE, Xcode, needs the full stack for its UI so we
wanted to fetch that in one big packet so we can give the pc and function names
without any additional packet traffic.)
https://reviews.llvm.org/D27289
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
