JosephTremoulet marked 2 inline comments as done. JosephTremoulet added inline comments.
================ Comment at: lldb/source/Plugins/Process/Utility/RegisterContextLLDB.cpp:1760 +void RegisterContextLLDB::PropagateTrapHandlerFlag( + lldb::UnwindPlanSP unwind_plan) { + if (unwind_plan->GetUnwindPlanForSignalTrap() != eLazyBoolYes) { ---------------- I'm a bit ambivalent about adding this part -- the downside is that it's not concretely helping today, because if an eh_frame record has the 'S' flag in its augmentation (which is what `unwind_Plan->GetUnwindPlanForSignalTrap()` reports), we'll have already decremented pc and generated unwind plans based on the prior function when initializing the register context. But the upside is that this connects the dots between the otherwise-unused bit on the unwind plan and the frame type, and will be in place should we subsequently add code to try the second function's unwind plan as a fallback. ================ Comment at: lldb/source/Target/StackFrame.cpp:297 Address lookup_addr(GetFrameCodeAddress()); - if (m_frame_index > 0 && lookup_addr.IsValid()) { + if (!m_behaves_like_zeroth_frame && lookup_addr.IsValid()) { addr_t offset = lookup_addr.GetOffset(); ---------------- I've verified that this fixes the issue with the function name in the stack trace mentioned in D63667, but I haven't figured a way to add a test to that effect without putting a brittle assumption about particular trap handler names in the test. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D64993/new/ https://reviews.llvm.org/D64993 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits