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