================
@@ -293,6 +293,9 @@ void RegisterContextUnwind::InitializeZerothFrame() {
return;
}
+ // Give the Architecture a chance to replace the UnwindPlan.
+ AdoptArchitectureUnwindPlan();
----------------
jasonmolenda wrote:
When we create a new stack frame (starting with the 0th), we find the Symbol
for that stack frame, and get its various UnwindPlans, or if there is no Symbol
for the stack frame, we fall back to using an ABI-provided Default Unwind Plan
(which just walks up the stack). Unwind Plans for a Symbol might come from
eh_frame, or debug_frame, or arm idx, Darwin compact unwind, or lldb's own
instruction emulation UnwindPlans. Some UnwindPlans are safe to use at any
instruction point ("asynchronous"), some are only guaranteed to be valid in the
body of the function ("throwable locations"), ("synchronous"), so this method
gets all UnwindPlans for a Symbol and decides which to use based on where we
are on the stack.
(there's also a tiny wrinkle of a "fast unwind plan" where only the caller's fp
& pc are being requested, and we can often service that request purely by
reading two entries of stack memory to walk the stack.)
We added a hook for the LanguageRuntime to override the function's normal
UnwindPlans based on some additional context - a register value having a
special value, or the name of the method. It's used by Swift for async context
funclets.
This PR is adding a new override based on the values of the parent frame. If
the parent's registers have a special value, the ArchitectureArm plugin will
override the locations of the caller's values with Armv7-M ARM mandated
exception return locations.
All of this is only done when the stack frame is first created. From that
point forward, we use the UnwindPlans registered here to provide register
values for the caller stack frame.
https://github.com/llvm/llvm-project/pull/153922
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
