[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077
show more ...
[lldb] [test] Update baseline test status for FreeBSDFixes #19721Fixes #18440Partially fixes bug #47660Fixes #47761Fixes #47763Sponsored by: The FreeBSD Foundation
[lldb] Fix thread syncrhonization TestThreadBacktraceRepeatlldb reports (and lldbutil.continue_to_breakpoint returns) a stop reasoneven for suspended threads. Fix the test to expect that.This wa
[lldb] Fix thread syncrhonization TestThreadBacktraceRepeatlldb reports (and lldbutil.continue_to_breakpoint returns) a stop reasoneven for suspended threads. Fix the test to expect that.This was making the test flaky, as most of the time, the two threadsstop simultaneously, and the synchronization code is not executed.
This test seems to pass on Linux, remove the x-fail.One of the tests in this test setup was copied from a more complex test, and I didn't knowif the setup or the subsequent parts of the test were
This test seems to pass on Linux, remove the x-fail.One of the tests in this test setup was copied from a more complex test, and I didn't knowif the setup or the subsequent parts of the test were the ones that fail on Linux. Lookslike it was the latter, so let's mark this succeeding.
Add a repeat command option for "thread backtrace --count N".This way if you have a long stack, you can issue "thread backtrace --count 10"and then subsequent <Return>-s will page you through the
Add a repeat command option for "thread backtrace --count N".This way if you have a long stack, you can issue "thread backtrace --count 10"and then subsequent <Return>-s will page you through the stack.This took a little more effort than just adding the repeat command, sincethe GetRepeatCommand API was returning a "const char *". That meant the commandhad to keep the repeat string alive, which is inconvenient. The originalAPI returned either a nullptr, or a const char *, so I changed the private API toreturn an llvm::Optional<std::string>. Most of the patch is propagating that change.Also, there was a little thinko in fetching the repeat command. We don'tfetch repeat commands for commands that aren't being added to history, whichis in general reasonable. And we don't add repeat commands to the history -also reasonable. But we do want the repeat command to be able to generatethe NEXT repeat command. So I adjusted the logic in HandleCommand to workthat way.Differential Revision: https://reviews.llvm.org/D119046