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>
Ensure step-avoid-regexp logs are emitted in the case where the regex has no capture groups. Without this change, the log is printed only if the regex has at least one capture group. Another change is to the log message: the first capture group has been removed from the message. There could be zero capture groups, and there could be two or more capture groups. Differential Revision: https://reviews.llvm.org/D119298
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.
A long time ago LLDB wanted to start using StringRef instead of C-Strings/ConstString but was blocked by the fact that the StringRef constructor that takes a C-string was asserting that the C-string isn't a nullptr. To workaround this, D24697 introduced a special function called `withNullAsEmpty` and that's what LLDB (and only LLDB) started to use to build StringRefs from C-strings. A bit later it seems that `withNullAsEmpty` was declared too awkward to use and instead the assert in the StringRef constructor got removed (see D24904). The rest of LLDB was then converted to StringRef by just calling the now perfectly usable implicit constructor. However, all the calls to `withNullAsEmpty` just remained and are now just strange artefacts in the code base that just look out of place. It's also curiously a LLDB-exclusive function and no other project ever called it since it's introduction half a decade ago. This patch removes all uses of `withNullAsEmpty`. The follow up will be to remove the function from StringRef. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D102597
`QueueThreadPlanForStepInRange` accepts a `step_into_target`, but the constructor for `ThreadPlanStepInRange` does not. Instead, a caller would optionally call `SetStepInTarget()` in a separate statement. This change adds `step_into_target` as a constructor argument. This simplifies construction of `ThreadPlanSP`, by avoiding a subsequent downcast and conditional assignment. This constructor is already used in downstream repos. Differential Revision: https://reviews.llvm.org/D96539
Update the rest of lldb to use std::make_unique<>. I used clang-tidy to automate this, which probably missed cases that are wrapped in ifdefs.
Differential Revision: https://reviews.llvm.org/D75711
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258