[Lldb-commits] [PATCH] D11415: Add jstopinfo support to llgs

[Greg Clayton]

> On Jul 30, 2015, at 5:09 AM, Pavel Labath <labath at google.com> wrote:
> 
> Hello Greg, Jim,
> 
> after adding jstopinfo support to LLGS, i am still getting a bunch of
> register read packets which access the program counter. These are
> coming from Thread::SetupForResume(), where we need to check whether a
> thread is on a breakpoint before letting it run. I would like to get
> rid of those packets (my preliminary tests show I can gain about 10%
> stepping speed improvement on my test app with 20 threads). I see two
> ways to go about this:
> 1. send the program counters as a part of the jstopinfo field. I will
> need to change the format of the field a bit, because the current
> assumption is that you do not include the threads which don't have a
> stop reason there, but we need the registers for every thread.

This is what we were going to do in debugserver. So yes, add update the docs to say send info for all threads (except the current only in the stop reply packet?) and send the PC values back.

> 2. cache the registers on the client side. These queries happen after
> we have previously done a vCont:s (as a part of ThreadPlanStepOver),
> so the client can determine that the other threads have not executed,
> and the registers are unchanged. We would still avoid caching the stop
> reason, since on OSX this can change even if the thread is not
> running, but I hope the registers remain the same.

This would also be possible, but I vote for solution #1.
> 
> All in all, the first approach is probably more easier to implement,
> but the second one sounds better to me architecturally, and has the
> benefit of caching all registers, and not just the PC.
> 
> Do you have any thoughts on this?

Lets start with solution #1 and see how that works out since it will be simple.

Greg