clayborg added a comment. Walter and I identified this at work, definitely want Jim to chime in on this.
================ Comment at: lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:2614-2616 m_thread_list_real.Clear(); m_thread_list.Clear(); + m_thread_plans.Clear(); ---------------- These things seem like they could go into a new function on the lldb_private::Process base class like: ``` void Process::ProcessDidExec() { m_thread_list_real.Clear(); m_thread_list.Clear(); m_thread_plans.Clear(); } ``` I know we are encourage people to use the lldb-server debugging route, but having common code in ProcessGDBRemote that each Process subclass will need to figure out how to do correctly seems like an easy fix. ================ Comment at: lldb/test/API/functionalities/exec/TestExec.py:96 # Run and we should stop due to exec process.Continue() ---------------- Do we need this continue if we did the step above? How does this test still work if the step was supposed to step over the exec? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93874/new/ https://reviews.llvm.org/D93874 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits