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
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
