Note that we do know when we've actively suspended threads, but in an average step, you will spend a fair bit of the time allowing all threads to run. So that wouldn't allow a very accurate accounting.
Jim > On Jun 3, 2016, at 8:42 AM, Jim Ingham via lldb-dev <lldb-dev@lists.llvm.org> > wrote: > > >> On Jun 3, 2016, at 2:22 AM, Abhishek Aggarwal via lldb-dev >> <lldb-dev@lists.llvm.org> wrote: >> >> Hi everyone >> >> While debugging an inferior with LLDB, for every stop event a new StopID is >> generated and this ID can be extracted from SBProcess::GetStopID() API. This >> ID indicates change in the state of the process between two stop events. >> >> As per my knowledge, in case of a multithreaded process this stop ID can't >> be used to exactly pin point the thread(s) of the process that suffered >> change in their states between two stop events. Is there a way to find out >> this information? > > That's not something the debugger tracks actively - when the process is > running we try to interfere with it as little as possible. But on systems > that have a way of getting per thread activity accounting, you could keep > track of that information each time we stop and use that information to > figure this out. > > debugserver on OS X does some reporting of CPU activity, but I don't think > that is per thread. You can fetch that with Process::GetAsyncProfileData(), > but at present that's just a pass-through (used by Xcode), lldb itself > doesn't do anything with this information. > > Jim > >> >> - Abhishek >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
