[Lldb-commits] [PATCH] Add new test for stress testing stack unwinding

[Tamas Berghammer]

I few general notes about this test case and why I prefer to generate test functions automatically:

- It won't be run as part of the default test suit because the running time is far to high (~1 minutes for a simple code and I plan to have a a lot of source file). As a consequences only people who working on stack unwinding have to touch this file (and even they can do most of the things without knowing how the tests are generated)
- Adding new chunk of source files should be very easy so we can get high coverage with small effort and we can run tests where the source files coming from a separate repository (e.g.: llvm nightly tests, gcc/g++ test suit, etc.) and we don't want to copy them into the lldb one


================
Comment at: test/functionalities/unwind/standard/TestStandardUnwind.py:32
@@ +31,3 @@
+        #                         instruction because it is special for some reason.) For these
+        #                         functions we will immediately do a step-out when we it them.
+
----------------
labath wrote:
> s/it/hit/?
Done

================
Comment at: test/functionalities/unwind/standard/TestStandardUnwind.py:56
@@ +55,3 @@
+
+        if not process:
+            self.fail("SBTarget.Launch() failed")
----------------
labath wrote:
> AssertTrue(process != None) ?
Done

================
Comment at: test/functionalities/unwind/standard/TestStandardUnwind.py:64
@@ +63,3 @@
+        # cases when we stuck in an infinite loop waiting for an event from the kernel while
+        # stepping (e.g.: in case of standard IO)
+        # TODO: Use better heuristic to detect when we have to do a step-out to increase the
----------------
labath wrote:
> I am confused by this comment. How will using step-out instead of step-inst help us unstuck a program which is waiting for STDIO? If it is waiting for an input event, it will keep waiting no matter how we step it...
Fixed. The issue is caused by a bug in LLDB where single stepping an inferior in ARM change the behavior of the inferior.

================
Comment at: test/functionalities/unwind/standard/TestStandardUnwind.py:73
@@ +72,3 @@
+            for i in range(process.GetNumThreads()):
+                thread = process.GetThreadAtIndex(0)
+
----------------
labath wrote:
> s/0/i/ ?
Done. Nice catch

================
Comment at: test/functionalities/unwind/standard/TestStandardUnwind.py:115
@@ +114,3 @@
+            except:
+                self.skipTest("Inferior not supported")
+            self.standard_unwind_tests()
----------------
labath wrote:
> What kind and how many compile errors were you encountering? I'm a bit worried that these skips everywhere will make it hard to figure out which tests are actually being run.
Primarily I expect 2 type of compile error because of the type of the test suit:
* Features not supported by the compiler we are currently testing with
* Source code collected from some source with copy/paste or with a script contains files what aren't compiling

http://reviews.llvm.org/D10454

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/