Swift is gaining asynchronous functions, which may not be executing when a function they call is executing. In the backtrace, we want to show the logical caller of this currently-executing function even though it is not present on the stack like a real frame. The LanguageRuntime can provide an UnwindPlan that will provide that function.
When the async function is actually executing, we'll use its normal UnwindPlans. But when it is not executing, we'll use the LanguageRuntime's UnwindPlan to show it in the stack.
The way this is actually implemented by the swift runtime is that the stack has a chain of these async-not-running functions and pointers to a data block with saved context for them, and as we walk the chain we will get back to real stack functions again. The swift language runtime uses a flag in the spilled fp register to tell when it should provide its special unwind plan.
This patch adds code to LanguageRuntime to see if any LanguageRuntime plugins can provide an UnwindPlan given a RegisterContext. It adds code to RegisterContextUnwind to see if the LanguageRuntime can provide an UnwindPlan before we start looking at the function's normal UnwindPlans, and uses the async unwind plan if it was provided. Pretty simple hooks out to the LanguageRuntime where the details are encapsulated.
Without interjecting a LanguageRuntime plugin in a live debug session, this isn't testable in standard lldb; in the swift branch of lldb I can have an API test that has some async calls on the stack and do a stack walk. But I need the LanguageRuntimeSwift support for one of these to get that to work.
Open to any comments or suggestions, not sure if anyone is really into the unwinder enough to spend time reviewing it.
I don't think we need this in the header file as we only use pointers to a RegisterContext. So move this to the .cpp file?