[Lldb-commits] [PATCH] D113810: Add the stop count to "statistics dump" in each target's dictionary.

Mon Nov 15 19:19:51 PST 2021

jingham added a comment.

In D113810#3132418 <https://reviews.llvm.org/D113810#3132418>, @clayborg wrote:

> In D113810#3128741 <https://reviews.llvm.org/D113810#3128741>, @jingham wrote:
>
>> The stop id includes all the user expression stops.  So the same "drive through code" could produce very different stop counts if you ran a bunch of `p`-s in one session but not the other.  You can't do better than that at present since we only track the natural/vrs. expression stop id for the last stop.  But if it mattered you could keep a separate "natural stop" counter and report that instead.  You can't quite get back to the natural stops by subtracting the number of expressions, because not all expressions run the target, and some do twice (if the one-thread run times out).
>
> I actually don't care about the number of natural user stops as the user will be aware of these stops. The info I am interested in is when a debug session has thousands of stops that auto resumed a debug session. This can happen if unix signals are used for program flow control or working around things. Android uses SIGSEGV for catching java NULL derefs and many times we will auto resume from these depending on signal settings. If a debug session is taking a long time it is nice to know. Some users might also have some python module that gets loaded and might end up setting a breakpoint with a callback that can auto resume.

IMO, the real solution for this issue is for lldb to invent (if there isn't already) a "auto-continue signals" packet, so we could tell the stub to restart from those signals w/o even telling lldb about it.

> The one metric I do want in the future is the time spent in stops that auto resume, like shared library loading stops where it stops, does some work, and auto resumes. The unix signals that cause stops where we auto resume would fit into that category. So one idea for the future it so start a timer each time we stop and then right before we resume stop the timer and report this time as something like "transparentStopTime" or something similar. Expression evaluation could also be counted in the time it took to evaluate expression as a separate stat.

Also, ThreadPlans stop a lot without any user-visible stops.  So a complicated step can also rack up the stops.  Right now, we don't do any accounting for "who is responsible" for auto-continuing, so you'd have to add that in.

>> I'm not sure that's terribly important, provided people doing this analysis know that both stops are getting counted, and this is a useful statistic either way.
>>
>> Anyway, other than that, LGTM.
>
> I was only looking for the total stops for now as it was really easy to add and could give us some insight to slow debug sessions if this number is really high.

Sounds fine.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113810