[Lldb-commits] [PATCH] D64993: Fix PC adjustment in StackFrame::GetSymbolContext

[Joseph Tremoulet via Phabricator via lldb-commits]

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