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?
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
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