The tests use a plugin based on the name from sys.platform.
Unfortunately that string includes the major version number in
Python 2.7, so the tests would look for builder_freebsd9.py,
builder_freebsd10.py, etc.
The issue doesn't affect Linux as Python returns 'linux2' also
on Linux 3.x -- see http://bugs.python.org/issue12326 for details.
It seems later versions of Python will drop the major version
number, so adopt this convention now for FreeBSD.
llvm-svn: 187121
- introduce new variable ARCHFLAG in make/Makefile.rules to switch between "-arch" on Mac and "-m" everywhere else
- update testcase makefiles to use LD_EXTRAS instead of LDFLAGS (the former interacts with Makefile.rules badly)
- special treatment for gcc 4.6: replace "-std=c++11" with "-std=c++0x" as the former is not handled correctly
- remove hardcoded "-arch" from test Makefile
This patch should not have any effect on lldb on Mac OS X.
llvm-svn: 173402
o Symbols.cpp:
Emit a warning message when dSYM does not match the binary.
o warnings/uuid:
Added regression test case.
o lldbtest.py:
Modified to allow test case writer to demand that the build command does not begin
with a clean first; required to make TestUUIDMismatchWanring.py work.
rdar://problem/10515708
llvm-svn: 149465
output from clang and llvm-gcc compiled program; both generate the correct debug
info with respect to the typedef scoped inside a namespace.
Add a TestBase.getCompiler(self) method which returns the compiler in effect the
test suite is now running with. Subclasses (like TestNamespace) can use it to
distinguish among different compilers.
llvm-svn: 119445
pass in a 'sender' arg to the buildDefault(), buildDsym(), buildDwarf(), and
cleanup() functions. The sender arg will be the test instance itself (i.e.,
an instance of TestBase). This is so that the relevant command execution can be
recorded in the TestBase.session object if sender is available.
The lldbtest.system() command has been modified to pop the 'sender' arg out of
the keyword arguments dictionary and use it as the test instance to facilitate
seesion recordings. An example is in test/types/AbstractBase.py:
def generic_type_tester(self, atoms, quotedDisplay=False):
"""Test that variables with basic types are displayed correctly."""
# First, capture the golden output emitted by the oracle, i.e., the
# series of printf statements.
go = system("./a.out", sender=self)
There are cases when sender is None. This is the case when the @classmethod is
involved in the use of these APIs. When this happens, there is no recording
into a session object, but printing on the sys.stderr is still honored if the
trace flag is ON.
An example is in test/settings/TestSettings.py:
@classmethod
def classCleanup(cls):
system(["/bin/sh", "-c", "rm -f output.txt"])
system(["/bin/sh", "-c", "rm -f stdout.txt"])
llvm-svn: 116648
files to a different top level directory than those specified on the command line.
When relocated, the test clanups normally performed afterwards after each test method
and after each test class will not be exercised at all. This allows for an easier
postmortem analysis of test failures.
Example:
./dotest.py -v -t -r /tmp/lldbtest types
will create a /tmp/lldbtest directory which houses the types directory and its supported
files.
Files modified:
o dotest.py, lldbtest.py:
Add logic to process '-r dir' option to support relocating the tests to a different
top level directory instead of exected in place.
o darwin.py, test/types/Makefile:
The 'make clean' should only clean the minimum .o and .d files.
llvm-svn: 116255
actually test-and-compare anything yet. The lldbtest.TestBase has an added
method setTearDownCleanup(dictionary=None) to facilitate running the cleanup
right after each data type test is run. The test case can pass a dictionary
object when registering the test case cleanup.
There is currently only int_type test in the repository.
llvm-svn: 114600
order to customize the running of the test suite. For the time being, the
supported customizations are:
o redirecting stdout and/or stderr
o specifying a list of compilers to build the test programs
o specifying a list of architectures to build the test programs for
Also checked into the examples/test directory some example files which
demonstrate the usage for the above customizations.
$ ./dotest.py -v -c ~/.lldbtest-config persistent_variables
$ cat ~/.lldbtest-config
sys.stderr = open("/tmp/lldbtest-stderr", "w")
sys.stdout = open("/tmp/lldbtest-stdout", "w")
compilers = ["gcc", "llvm-gcc"]
archs = ["x86_64", "i386"]
$ cat /tmp/lldbtest-stderr
----------------------------------------------------------------------
Collected 1 test
Configuration: arch=x86_64 compiler=gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok
----------------------------------------------------------------------
Ran 1 test in 1.397s
OK
Configuration: arch=x86_64 compiler=llvm-gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok
----------------------------------------------------------------------
Ran 1 test in 1.282s
OK
Configuration: arch=i386 compiler=gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok
----------------------------------------------------------------------
Ran 1 test in 1.297s
OK
Configuration: arch=i386 compiler=llvm-gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok
----------------------------------------------------------------------
Ran 1 test in 1.269s
OK
$ cat /tmp/lldbtest-stdout
$
llvm-svn: 114380
This will remove the confusion experienced when previous test runs left some
files (both intermediate or by-product as a result of the test).
lldbtest.TestBase defines a classmethod tearDownClass(cls) which invokes the
platform-specific cleanup() function as defined by the plugin; after that, it
invokes a subclass-specific function classCleanup(cls) if defined; and, finally,
it restores the old working directory.
An example of classCleanup(cls) is in settings/TestSettings.py:
@classmethod
def classCleanup(cls):
system(["/bin/sh", "-c", "rm output.txt"])
where it deletes the by-product "output.txt" as a result of running a.out.
llvm-svn: 114058
the binaries.
If the build* function is passed the compiler argument, for example, 'llvm-gcc',
it is passed as a make variable to the make command. Otherwise, we check the
LLDB_CC environment variable; if it is defined, it is passed as a make variable
to the make command.
If neither the compiler keyword argument nor the LLDB_CC environment variable is
specified, no CC make variable is passed to the make command. The Makefile gets
to define the default CC being used.
--------------------------------------------------------------------------------
Example usage follows:
o Via the keyword argument:
class ArrayTypesTestCase(TestBase):
mydir = "array_types"
@unittest2.skipUnless(sys.platform.startswith("darwin"), "requires Darwin")
def test_with_dsym_and_run_command(self):
"""Test 'frame variable var_name' on some variables with array types."""
self.buildDsym(compiler='llvm-gcc')
self.array_types()
...
o Via LLDB_CC environment variable:
$ LLDB_CC=llvm-gcc ./dotest.py -v -t array_types
----------------------------------------------------------------------
Collected 4 tests
test_with_dsym_and_python_api (TestArrayTypes.ArrayTypesTestCase)
Use Python APIs to inspect variables with array types. ...
os command: [['/bin/sh', '-c', 'make clean; make MAKE_DSYM=YES CC=llvm-gcc']]
output: rm -rf "a.out" "a.out.dSYM" main.o main.d
llvm-gcc -arch x86_64 -gdwarf-2 -O0 -arch x86_64 -gdwarf-2 -O0 -c -o main.o main.c
llvm-gcc -arch x86_64 -gdwarf-2 -O0 main.o -o "a.out"
/usr/bin/dsymutil -o "a.out.dSYM" "a.out"
...
llvm-svn: 113781
to delegate the building of binaries to a sys.platform-sepcific plugin.
Modified the dotest.py test driver to add the "plugins" directory to the
PYTHONPATH as well.
darwin.py is the Mac OS X plugin module.
llvm-svn: 112606
Ed Maste