Add a new idea of a "fallback" UnwindPlan to the RegisterContextLLDB
class. If we try to unwind a stack frame to find a caller stack frame, and we fail to get a valid-looking frame, AND if the UnwindPlan we used is an assembly-inspection based UnwindPlan, then we should throw away the assembly-inspection UnwindPlan and try unwinding with the architectural default UnwindPlan. This code path won't be taken if eh_frame unwind instructions are available - lldb will always prefer those once it's off the zeroth frame. The problem I'm trying to fix here is the class of unwind failures that happen when we have hand-written assembly on the stack, with no eh_frame, and lldb's assembly parser fails to understand the assembly. People usually write their hand-written assembly to follow the frame-pointer-preserving conventions of the platform so the architectural default UnwindPlan will often work. We won't have the spill location for most of the non-volatile registers if we fall back to this, but it's better than stopping the unwind prematurely. This is a bit of a tricky change that I believe is correct, but if we get unwinds that go of into the weeds / unwind bogus frames at the end of the stack, I'll need to revisit it. <rdar://problem/16099440> llvm-svn: 201839
Loading
Please register or sign in to comment