clayborg added a comment. 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. 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. > 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. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113810/new/ https://reviews.llvm.org/D113810 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
