labath marked 2 inline comments as done. labath added inline comments.
================ Comment at: source/Core/Module.cpp:1451-1454 + // Clear the unwind table too, as that may also be affected by the + // symbol file information. + m_unwind_table.reset(); + ---------------- jasonmolenda wrote: > clayborg wrote: > > Are we sure no one is holding onto info that was given out from an existing > > UnwindTable? What if we do a backtrace, then load symbol files and then do > > another backtrace? Seems like we will want to keep our existing info and > > just call m_unwind_table->Clear()? > I THINK it will be OK. RegisterContextLLDB holds shared pointers to the > UnwindPlans that it got from the UnwindTable, so those will stay alive. An > UnwindPlan doesn't refer back to the UnwindTable it came from. I agree with Jason. Nobody should store any pointers to the unwind table, and the FuncUnwinders and UnwindPlan objects are already handed out as shared pointers (but those shouldn't persist for long either, or otherwise our new unwind info wouldn't be effective). If we find a good reason to store the old unwind table, we can always do the thing like we do for SymbolFiles (where the Module keeps a list of all SymbolFile objects it ever had), but I hope that will not be necessary. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58347/new/ https://reviews.llvm.org/D58347 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
