[Lldb-commits] [PATCH] D74398: [lldb-server] jThreadsInfo returns stack memory

Sat Mar 21 21:22:15 PDT 2020

jasonmolenda added a comment.

In D74398#1935043 <https://reviews.llvm.org/D74398#1935043>, @jarin wrote:

> Regarding the packet savings - there are still things that worry me.
>
> First of all, when lldb CLI stops on a breakpoint, it will first unwind top of the stack of each thread as part of ThreadList::ShouldStop. This sends lots of "x" packets to lldb-server and only then issues jThreadInfo, which then replies with the stack memory uselessly (with my patch). I am yet to investigate why the CLI does that.

I haven't looked into this, but this sound like the difference between a "private stop" and a "public stop".  When you do a source-level "next" command, lldb will put breakpoints on branches/function calls, run to those, then instruction step those instructions, etc.  Each time it stops at these breakpoints or instruction-steps.  Each of these stops are called private stops - the UI layer (lldb command line driver or the SB API driver) never hear about these.  When we've completed executing the instructions for that source line, then we declare this to be a "public stop" - this is when lldb driver or SB API driver, and the user, are notified that execution has stopped.

jThreadInfo is probably only retrieved when there is a public stop.  debugserver puts two words of the current stack frame and the caller's stack frame in the questionmark (T05 etc) packet along with register contents for the frame that stopped.  The stepping thread plans need to know the current stack frame and the caller stack frame, to be sure that you didn't just step out of a function call or something.

For all the threads that aren't stepping, lldb should only need to know the current pc value - in the questionmark stop packet I also include the thread-pcs: list of pc values for each thread so we don't query them.

Look over the packet log while thinking about the difference between private stops and public stops and I think it might be easier to understand what's going on.

> My patch saves messages when we start stepping after the breakpoint - in my example with a hundred threads, when we stop on a breakpoint, take a step and then do "thread list", there are no additional 'x' packets sent to lldb-server for the "thread list" command; without my patch there is a packet per-thread. In our VS extension, this seems to help quite a bit, but I am not so sure about the CLI.
> 
>   It also feels like jThreadsInfo might not the best place to send the stacks - I am wondering whether jstopinfo in the vCont/c packet response would be a better place (even though the encoding of that is quite terrible). What do you think?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D74398/new/

https://reviews.llvm.org/D74398