This PR introduces a new `ThreadPlanSingleThreadTimeout` that will be used to address potential deadlock during single-thread stepping. While debugging a target with a non-trivial number of threads (around 5000 threads in one example target), we noticed that a simple step over can take as long as 10 seconds. Enabling single-thread stepping mode significantly reduces the stepping time to around 3 seconds. However, this can introduce deadlock if we try to step over a method that depends on other threads to release a lock. To address this issue, we introduce a new `ThreadPlanSingleThreadTimeout` that can be controlled by the `target.process.thread.single-thread-plan-timeout` setting during single-thread stepping mode. The concept involves counting the elapsed time since the last internal stop to detect overall stepping progress. Once a timeout occurs, we assume the target is not making progress due to a potential deadlock, as mentioned above. We then send a new async interrupt, resume all threads, and `ThreadPlanSingleThreadTimeout` completes its task. To support this design, the major changes made in this PR are: 1. `ThreadPlanSingleThreadTimeout` is popped during every internal stop and reset (re-pushed) to the top of the stack (as a leaf node) during resume. This is achieved by always returning `true` from `ThreadPlanSingleThreadTimeout::DoPlanExplainsStop()` and `ThreadPlanSingleThreadTimeout::MischiefManaged()`. 2. A new thread-specific async interrupt stop is introduced, which can be detected/consumed by `ThreadPlanSingleThreadTimeout`. 3. The clearing of branch breakpoints in the range thread plan has been moved from `DoPlanExplainsStop()` to `ShouldStop()`, as it is not guaranteed that it will be called. The detailed design is discussed in the RFC below: [https://discourse.llvm.org/t/improve-single-thread-stepping/74599](https://discourse.llvm.org/t/improve-single-thread-stepping/74599) --------- Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
Step over thread plans were claiming to explain the fork stop reasons, which prevented the default fork logic (detaching from the child process) from kicking in. This patch changes that. Differential Revision: https://reviews.llvm.org/D141605
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should. After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
[NFC] As part of using inclusive language within the llvm project, this patch renames master plan to controlling plan in lldb. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D113019
Change `ThreadPlanStack::PopPlan` and `::DiscardPlan` to not do the following: 1. Move the last plan, leaving a moved `ThreadPlanSP` in the plans vector 2. Operate on the last plan 3. Pop the last plan off the plans vector This leaves a period of time where the last element in the plans vector has been moved. I am not sure what, if any, guarantees there are when doing this, but it seems like it would/could leave a null `ThreadPlanSP` in the container. There are asserts in place to prevent empty/null `ThreadPlanSP` instances from being pushed on to the stack, and so this could break that invariant during multithreaded access to the thread plan stack. An open question is whether this use of `std::move` was the result of a measure performance problem. Differential Revision: https://reviews.llvm.org/D106171
Rename `stop_vote` and `run_vote` to `report_stop_vote` and `report_run_vote` respectively. These variables are limited to logic involving (event) reporting only. This naming is intended to make their context more clear. Differential Revision: https://reviews.llvm.org/D96917
Delete unused `EnableTracer()` and `SetTracer()` functions on `Thread`. By deleting these, their `ThreadPlan` counterparts also become unused. Then, by deleting `ThreadPlanStack::EnableTracer`, `EnableSingleStep` becomes unused. With no more callers to `EnableSingleStep`, the value `m_single_step` is always true and can be removed as well. Differential Revision: https://reviews.llvm.org/D96666
While learning about ThreadPlan, I did a bit of cleanup: * Remove unused code * Move functions to protected where applicable * Remove virtual for functions that are not overridden Differential Revision: https://reviews.llvm.org/D96277