[Lldb-commits] [PATCH] Add new test for stress testing stack unwinding
tberghammer at google.com
Tue Jun 16 16:17:54 PDT 2015
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.
Comment at: test/functionalities/unwind/standard/TestStandardUnwind.py:56
@@ +55,3 @@
+ if not process:
+ self.fail("SBTarget.Launch() failed")
> AssertTrue(process != None) ?
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
> 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)
> s/0/i/ ?
Done. Nice catch
Comment at: test/functionalities/unwind/standard/TestStandardUnwind.py:115
@@ +114,3 @@
+ self.skipTest("Inferior not supported")
> 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
More information about the lldb-commits