Back out r221229 -- instead of trying to identify the end of the unwind,

let's let lldb try the arch default unwind every time but not destructively --
it doesn't permanently replace the main unwind method for that function from
now on.

This fix is for <rdar://problem/18683658>.  

I tested it against Ryan Brown's go program test case and also a
collection of core files of tricky unwind scenarios 
<rdar://problem/15664282> <rdar://problem/15835846>
<rdar://problem/15982682> <rdar://problem/16099440>
<rdar://problem/17364005> <rdar://problem/18556719> 
that I've fixed over the last 6-9 months.

llvm-svn: 221238

1 files changed, 0 insertions, 7 deletions

diff --git a/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.h b/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.h
index d272073de55..ff0b77488eb 100644
--- a/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.h
+++ b/lldb/source/Plugins/Process/Utility/RegisterContextLLDB.h
@@ -73,9 +73,6 @@ public:
     IsValid () const;
 
     bool
-    IsCompletedStackWalk () const;
-
-    bool
     IsTrapHandlerFrame () const;
 
     bool
@@ -243,10 +240,6 @@ private:
 
     lldb_private::UnwindLLDB& m_parent_unwind;    // The UnwindLLDB that is creating this RegisterContextLLDB
 
-    bool m_completed_stack_walk;                  // indicates that we completed a full stack walk 
-                                                  // (this frame is likely eNotAValidFrame aka !IsValid())
-                                                  // and we should not continue trying to unwind
-
     //------------------------------------------------------------------
     // For RegisterContextLLDB only
     //------------------------------------------------------------------