labath accepted this revision. labath added a comment. This revision is now accepted and ready to land.
In D79308#2017377 <https://reviews.llvm.org/D79308#2017377>, @jarin wrote: > Yeah, I considered something like that, but then I thought it would be better > if the "other" thread only runs code that we completely control. In my patch, > the "other" thread is guaranteed to be in thread_func after we hit the > breakpoint. In your suggested inferior, it could be still in > pseudo_barrier_wait. If you feel stepping in external code is safe, I am > happy to rewrite the test to the simpler version. The main reason that "pseudo_barrier_wait" even exists is so that we can drive multiple test threads to very precise points in the code, so I wouldn't really call it "external" code. If we were doing something more complicated to the thread (like playing with the line numbers for instance, then I might get worried, but given that all we need is to do an instruction step, I think this is perfectly safe, and a lot more understandable than the previous version. ================ Comment at: lldb/test/API/functionalities/thread/break_step_other/TestThreadBreakStepOther.py:21 +class ThreadBreakStepOtherTestCase(TestBase): + mydir = TestBase.compute_mydir(__file__) + ---------------- You can add `NO_DEBUG_INFO_TESTCASE = True` here. ================ Comment at: lldb/test/API/functionalities/thread/break_step_other/main.cpp:23-25 + while (true) { + g_foo = ++i; + } ---------------- Just a small tweak to ensure the inferior exits if anything happens to the debugger (e.g., it crashes) ``` volatile int i = 0; while (g_foo == 0) ++i; t.join(); ``` (and change `g_foo = 0` to `g_foo = 1` in thread_func above). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79308/new/ https://reviews.llvm.org/D79308 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
