diff options
Diffstat (limited to 'www/test.html')
| -rw-r--r-- | www/test.html | 132 |
1 files changed, 132 insertions, 0 deletions
diff --git a/www/test.html b/www/test.html new file mode 100644 index 000000000000..b40e0ff4ddd5 --- /dev/null +++ b/www/test.html @@ -0,0 +1,132 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> + <link href="style.css" rel="stylesheet" type="text/css" /> + <title>Testing LLDB</title> +</head> +<body> + <div class="www_title"> + The <strong>LLDB</strong> Debugger + </div> + + <div id="container"> + <div id="content"> + + <!--#include virtual="sidebar.incl"--> + + <div id="middle"> + <div class="post"> + <h1 class="postheader">Testing LLDB</h1> + <div class="postcontent"> + <p> + The LLDB test suite consists of Python scripts located under the + <tt>test</tt> directory. Each script contains a number of test cases and is usually + accompanied by a C (C++, ObjC, etc.) source file. Each test first compiles the + source file and then uses LLDB to debug the resulting executable. The tests verify + both the LLDB command line interface and the scripting API. + </p> + + <p> + The easiest way to run the LLDB test suite is to use the <tt>check-lldb</tt> build + target. By default, the <tt>check-lldb</tt> target builds the test programs with + the same compiler that was used to build LLDB. To build the tests with a different + compiler, you can set the <tt>LLDB_TEST_COMPILER</tt> CMake variable. It is possible to + customize the architecture of the test binaries and compiler used by appending -A + and -C options respectively to the CMake variable <tt>LLDB_TEST_USER_ARGS</tt>. For + example, to test LLDB against 32-bit binaries + built with a custom version of clang, do: + </p> + <code> + <br />> cmake -DLLDB_TEST_ARGS="-A i386 -C /path/to/custom/clang" -G Ninja + <br />> ninja check-lldb + </code> + <p>Note that multiple -A and -C flags can be specified to <tt>LLDB_TEST_USER_ARGS</tt>.</p> + <p>Note that on NetBSD you must export <tt>LD_LIBRARY_PATH=$PWD/lib</tt> in your environment. This is due to lack of + the <tt>$ORIGIN</tt> linker feature.</p> + <p> + In addition to running all the LLDB test suites with the "check-lldb" CMake target above, it is possible to + run individual LLDB tests. For example, to run the test cases defined in TestInferiorCrashing.py, run: + </p> + <code> + <br />> cd $lldb/test + <br />> python dotest.py --executable <path-to-lldb> -p TestInferiorCrashing.py + </code> + <p> + In addition to running a test by name, it is also possible to specify a directory path to <tt>dotest.py</tt> + in order to run all the tests under that directory. For example, to run all the tests under the + 'functionalities/data-formatter' directory, run: + </p> + <code> + <br />> python dotest.py --executable <path-to-lldb> functionalities/data-formatter + </code> + <p> + To dump additional information to <tt>stdout</tt> about how the test harness is driving LLDB, run + <tt>dotest.py</tt> with the <tt>-t</tt> flag. Many more options that are available. To see a list of all of them, run: + </p> + <code> + <br />> python dotest.py -h + </code> + + <p> + The dotest.py script runs tests in parallel by default. + To disable the parallel test running feature, use the + <code>--no-multiprocess</code> flag. The number of + concurrent tests is controlled by + the <code>LLDB_TEST_THREADS</code> environment variable + or the <code>--threads</code> command line parameter. + The default value is the number of CPU cores on your + system. + </p> + <p> + The parallel test running feature will handle an + additional <code>--test-subdir SUBDIR</code> arg. When + specified, SUBDIR is relative to the root test directory + and will limit all parallel test running to that + subdirectory's tree of tests. + </p> + <p> + The parallel test runner will run all tests within a + given directory serially, but will run multiple + directories concurrently. Thus, as a test writer, we + provide serialized test run semantics within a + directory. Note child directories are considered + entirely separate, so two child directories could be + running in parallel with a parent directory. + </p> + + <h3>Running the test-suite remotely</h3> + + <p> + Running the test-suite remotely is similar to the process of running a local test + suite, but there are two things to have in mind: + </p> + <ul> + <li> + You must have the <code>lldb-server</code> running on the remote system, ready to + accept multiple connections. For more information on how to setup remote + debugging see the <a href="remote.html">Remote debugging</a> page. + </li> + <li> + You must tell the test-suite how to connect to the remote system. This is + achieved using the <code>--platform-name</code>, <code>--platform-url</code> and + <code>--platform-working-dir</code> parameters to <code>dotest.py</code>. These + parameters correspond to the <code>platform select</code> and <code>platform + connect</code> LLDB commands. You will usually also need to specify the compiler and + architecture for the remote system. + </li> + </ul> + <p> + Currently, running the remote test suite is supported only with + <code>dotest.py</code> (or <code>dosep.py</code> with a single thread), but we + expect this issue to be addressed in the near future. + </p> + + </div> + <div class="postfooter"></div> + </div> + </div> + </div> + </div> +</body> +</html> |