Jason Molenda 31d7ad4ecf 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

2014-02-21 05:20:25 +00:00

13 KiB

Raw Blame History

View Raw