[Lldb-commits] [PATCH] D75711: [NFC] Have ThreadPlans hold onto the Process & TID, rather than the Thread

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

As long as the keeping thread plans around for threads that aren't there is only enabled when OS plug-in is around, I am fine with this direction. One questions: do we currently only allow stepping on real threads or OS threads that are backed by real threads right now? And if an OS thread is backed by a real thread, do we associate the step plan with the OS thread ID or the real thread ID (the core)? If we use the OS thread ID, another way to potentially fix this is to know in a thread plan that we are stepping an OS thread, and avoid fetching the complete OS list of threads for non public stops, but only fetch the thread list for any OS threads that have active thread plans and any OS threads for threads that are active on a core. Then we don't end up fetching all OS threads all the time for stepping, but it does allow us to maintain and track our OS thread correctly. This would require changes to the OS plug-ins where getting the thread list needs to be able to grab only the OS threads that are on core, and we can manually fetch the OS thread info for any thread plans, and the plug-in would still need to be able to fetch the complete list on public stop events.

Stepping on Android could really benefit from some of the plans you mention where we might not end up fetching all of the thread IDs on a stop from the GDB remote. One idea is, when we do a continue where we specify only one thread to run, or only a few threads get to run, then the stop reply would only need to mention these threads and any new threads that showed up during the last resume. We can safely assume any other threads were suspended and have the exact same state. This will take some careful tracking in the Process class, but it could be done. For some reason Android has 150 threads running a lot of times which causes stepping to take a while on many cases. A lot of these issues were fixed with my patches submitted a while back where when we are stepping over stuff, we don't always stop at all branches, but only stop at branches that are not function calls, but stepping can still be quite slow.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75711