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