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

[Pavel Labath]

Ok, I can sort of see where you are going with this. I guess auto-generating test cases makes sense for this use-case. I'd be interested to hear what the others make of it though.

In any case, before checking this in, I would propose to add at least a couple of (hand-written?) test cases, so that it is possible to verify that the test logic actually works. I propose two test cases: one single threaded, and one multi.


================
Comment at: test/functionalities/unwind/standard/TestStandardUnwind.py:44
@@ +43,3 @@
+                "__aeabi_ldivmod",       # Do a "push {sp}" what is not handled correctly
+                "__aeabi_uldivmod",      # Do a "push {sp}" what is not handled correctly
+            ]
----------------
As I understand it, the idea is to use this list as a sort of an XFAIL list. In that case, maybe we should add a link to the relevant bug, where applicable?

================
Comment at: test/functionalities/unwind/standard/TestStandardUnwind.py:48
@@ +47,3 @@
+                "__sync_fetch_and_add_4", # Calls into a special SO where we can't set a breakpoint
+                "pthread_mutex_lock",     # Uses ldrex and strex what interfiers with the software single stepping
+                "pthread_mutex_unlock",   # Uses ldrex and strex what interfiers with the software single stepping
----------------
interferes

================
Comment at: test/functionalities/unwind/standard/TestStandardUnwind.py:115
@@ +114,3 @@
+            except:
+                self.skipTest("Inferior not supported")
+            self.standard_unwind_tests()
----------------
tberghammer wrote:
> 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
> Features not supported by the compiler we are currently testing with
Ok, that makes sense.
> Source code collected from some source with copy/paste or with a script contains files what aren't compiling
Makes sense if testing against a foreign file collection, but if you are going to check those files in, I would expect you to go through them (automatically if you want) and make sure they make sense, so that we don't end up with a bunch of garbage in the repository.

http://reviews.llvm.org/D10454

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