[Lldb-commits] [PATCH] D27289: Return "thread-pcs" in jstopinfo on Linux/Android.

[Jason Molenda via Phabricator via lldb-commits]

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