[Lldb-commits] [PATCH] D96839: Add a callout to the LanguageRuntime to override the normal UnwindPlan used for a frame

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added inline comments.


================
Comment at: lldb/include/lldb/Target/LanguageRuntime.h:188
+  GetAsyncedFrameUnwindPlan(lldb_private::Thread &thread,
+                            lldb_private::RegisterContext *regctx);
+
----------------
clayborg wrote:
> Any reason we are passing in the register context and the thread instead of a stack frame? a stack frame has access to the register context and to the thread it belongs to. Or is this register context just a raw register context that was extracted from somewhere in memory?
I'll rethink this though, but I don't think we have a StackFrame yet.  We're constructing the register context and we'll use that in creating the stack frame in a bit.  I might be off-by-one, these parts of the unwinder can take some mental gymnastics to model properly when you're changing things.


================
Comment at: lldb/include/lldb/Target/LanguageRuntime.h:192
+  virtual lldb::UnwindPlanSP
+  GetAsyncedFrameForThisLanguage(lldb_private::Thread &thread,
+                                 lldb_private::RegisterContext *regctx) {
----------------
clayborg wrote:
> What does "ThisLanguage" this mean? Is it the language of the stack frame that owns "regctx"? Should we pass in the current stack frame instead of a register context?
Yeah it's not a great method name.  The LanguageRuntime base class has a list of registered LanguageRuntime plugins.  I want to iterate over them, seeing if any LanguageRuntime can provide one of these special one-off UnwindPlans.  Tbh the top-level method GetAsyncedFrameForThisLanguage could have gone in Process and it could call a method of the same name in all the LanguageRuntime plugins, would end up working the same.  


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D96839/new/

https://reviews.llvm.org/D96839